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the  specified  semantics  of  the  language.  In  addition,  ARLO  itself  - 

as  a  language  for  expressing  and  compiling  partial  and  complete  language 

specifications  - is  described  and  ^interpted  in  the  same  manner  as  the 

languages  it  describes  and  implements.  This  self  description  can  be  extended 
or  modified  to  expand  or  alter  the  expressive  power  of  ARLO's  initial 

configuration.  Languages  which  describe  themselves  -  like  ARLO  - 

provide  powerful  mediums  for  systems  which  perform  automatic  self-modification, 
optimization,  debugging,  or  documentation.  AI  systems  implemented  in  such 
a  self-descriptive  language  can  reflect  on  their  own  capabilities,  applying 
general  problem  solving  and  learning  strategies  to  enlarge  or  correct  them. 
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Reading  this  thesis 

The  paper  iu  your  hands  began  as  a  primer  for  ARLO  users,  bul  with  time  it  has  --  much  like  ARLO 
itself  grown,  mutated,  and  gone  through  rearrangements  The  bulk  of  this  paper  discusses  representation 
language  languages  in  general,  and  the  detailed  implementation  of  ARLO  in  particular.  These  discussions  are 
followed  by  two  examples  presenting  ARLO  as  both  a  system-building  tool  and  as  a  framework  for  building 
auto-analytical  systems. 

The  first  chapter  presents  motivations  for  representing  representations,  and  makes  some  first  steps 
towards  generally  characterizing  what  is  meant  technically  (as  opposed  to  philosophically)  -  in  the  AI 
community  by  ‘‘representation.”  It  then  introduces  ARLO  as  a  language  for  representing  representation 
languages.  The  chapter  closes  with  a  scenario  of  a  new  user  being  slowly  introduced  to  ARLO’s  functionality, 
features,  and  faclities. 

The  second  chapter  steps  behind  the  scenes  to  talk  about  ARLO's  internal  construction,  detailing  how 
the  mechanisms  of  the  preceding  scenario  actually  operate. 

The  third  and  fourth  chapters  of  the  thesis  portray  ARLO  in  two  different  roles.  In  the  third  chapter, 
a  toy  language  for  describing  people  and  their  interrelations  is  implemented;  this  language  is  then  used  to 
describe  the  members  of  an  imaginary  research  lab.  This  embedded  language  and  database  is  then  examined 
and  extended  in  an  annotated  script  of  a  user’s  interaction  with  the  system.  This  script  illustrates  ARLO's 
facilities  for  accessing,  modifying,  and  extending  its  representations. 

The  fourth  chapter  presents  an  example  of  tools  which  examine  representations  and  descriptions  de¬ 
veloped  in  ARLO  or  its  extensions.  It  describes  an  explanation  system  which  takes  a  collection  of  ARLO 
structures  --  describing  either  some  domain,  some  representation  language,  or  both  —  and  produces  an  en- 
glish  description  of  the  structures.  The  focus  and  organization  of  this  description  is  generated  from  general 
properties  of  its  topical  structures  extracted  for  the  structures  themselves.  The  explanation  mechanism  is 
then  applied  —  as  a  demonstration  —  to  automatically  generate  a  description  of  the  in-core  implementation 
of  the  previous  example  (the  laboratory  database). 

Finally,  in  the  appendices,  this  explanation  mechanism  is  applied  to  both  itself  (the  explanation  system) 
and  the  core  of  ARLO’s  default  configuration. 
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Chapter  ] 

ARLO:  Representing  Representations 


In  Hof80'.  Hofstader  makes  the  sweeping  claim  that  AI  advance s  are  language  advances.  While  this  is 
certainly  too  broad  a  generalization,  it  has  a  hefty  component  of  truth:  we  develop  languages  which  reflect 
our  developing  theories  so  that  we  may  actually  bring  those  theories  to  the  touchstone  of  implementation 
As  our  proposals  and  theories  advance  and  change,  so  do  the  languages  —  the  abstractions  and  primitives  — 
used  to  implement  them.  If  we  are  really  engaged  in  experimental  epistemology,  as  some  have  characterized 
AI,  then  the  languages  and  representations  we  develop  are  the  burners,  flasks,  lasers,  and  spectrographs  of 
our  experimental  laboratory. 

But  what  precisely  is  an  “AI  language”?  What  distinguishes  an  AI  language  from  a  conventional  pro¬ 
gramming  language  used  to  write  intelligent  programs'7  One  distinction  we  might  draw  is  that  AI  languages 
are  languages  embodying  some  theory  of  AI  programs.  The  facilities  which  an  AI  language  provides  generally 
grow  from  observation  of  the  sorts  of  things  which  AI  programs  —  written  in  either  conventional  languages 
or  other  AI  languages  —  tend  to  do:  pattern  matching,  heuristic  search,  property  inheritance,  etc.  A  given 
AI  language  combines  a  collection  of  these  extracted  primitives  with  a  few  organizational  principles  —  mo¬ 
tivated  both  theoretically  and  technically  -  to  provide  a  framework  in  which  writing  intelligent  programs 
—  encoding  human  knowledge  and  expertise  —  is  easier  and  more  elegant 

Aet  in  a  deeper  sense,  an  A I  language  does  not  merely  provide  a  framework  for  expressing  knowledge 
and  expertise  in  convenient  ways:  it  implicitly  embodies  some  knowledge  itself.  The  knowledge  it  embodies 
is  the  ontological  foundation  upon  which  programs  or  systems  in  it  build:  properties  inherit  in  this  way. 
two  things  are  similar  (match)  by  this  criterion,  logical  inferences  are  invalidated  when  this  happens,  and 
so  forth.  In  this  sense,  a  given  AI  language  is  an  AI  program  itself,  embodying  a  particular  theory  of  how 
a  particulai  part  of  the  world  works.  It's  just  that,  in  the  case  of  representation  languages,  the  parts  of 
the  world  captured  are  techniques  for  representation  and  reasoning.  But  if  an  AI  language  is  itself  an  AI 
ptogram  might  we  build  a  language  whose  “domain”  is  these  AI  languages' 
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This  paper  describes  ARLO,  a  representation  language  language  which  describes  and  implements 
representation  languages,  including  itself.  Descriptions  of  languages  in  ARLO  are  compiled  into  implementa¬ 
tions,  so  that  describing  a  given  language  in  ARLO  —  in  a  sufficiently  precise  way  —  generates  a  reasonably 
efficient  implementation  of  the  language  as  well  as  a  manipulable  description  of  its  semantics  and  behaviour 
The  first  RLL  ( representation  language  language)  was  developed  at  Stanford  by  Greiner  and  Lenat 
GreetO;.  Their  implementation  was  dubbed  RLL-1,  and  a  version  of  it  is  used  in  Lenat’s  automated  discovery 
program,  Eurisko[Len83j.  Eurisko  uses  an  accumulated  body  of  heuristics  to  guide  the  mutative  evolution  of 
representations  and  heuristics  for  various  domains.  A  reflexive  A1  language  —  able  to  talk  about  and  modify 
itself  and  languages  embedded  in  it  —  is  ideal  for  this  sort  of  evolutionary  development  of  concepts  and 
expertise.  ARLO  was  originally  conceived  as  a  Common  Lisp  [Ste84j  version  of  the  RLL-1,  but  has  diverged 
from  it  in  several  important  directions. 

1.1  What  Good  is  Representing  Representations? 

Why  do  we  need  —  or  want  —  a  language  for  describing  representation  languages?  Our  programming 
languages  already  procedurally  describe  the  representational  mechanisms  we  use.  What  is  the  point  of 
having  an  intermediate  language  for  describing  those  mechanisms? 

An  answer  to  this  challenge  may  be  revealed  by  describing  what  an  RLL  offers  two  distinct  classes  of 
us#rs:  the  expert-  systems  developer  and  the  A1  researcher.  To  the  expert  systems  programmer  tailoring 
a  representation  for  some  understood  domain,  an  RLL  provides  systems  programming  tools  for  developing 
a  system’s  representational  paradigms  and  primitives.  To  the  AI  researcher  building  a  program  whose 
understanding  of  its  domain  evolves  through  exploration  and  inner  cogitation,  an  RLL  makes  a  program’s 
understanding  of  a  domain  into  a  manipulable  stuff  which  the  program  itself  can  access. 

1.1.1  RLL’s  as  implementation  languages 

The  tools  which  an  RLL  gives  the  implementor  of  an  expert  system  are  primarily  system  programming  tools — 
tools  which  make  the  task  of  developing  and  debugging  a  given  representation  for  a  particular  domain  both 
faster  and  easier.  The  features  that  make  an  RLL  a  powerful  development  environment  for  expert  reasoning 
systems  are  largely  the  same  features  that  make  modern  LISP  systems  ideal  for  fast  prototyping  of  any  sort 
of  complicated  system.  LISP  is  a  powerful  development  environment  because  (among  other  factors): 

•  Programs  and  data  are  uniformly  represented;  the  same  tools  used  to  describe  and  modify  programs 
can  be  used  to  describe  and  modify  data  structures. 

•  Embedded  Languages  —  building  on  LISP’s  data  and  program  structures  —  can  take  advantage  of 
already  existing  facilities  of  the  LISP  environment. 

•  The  language  can  be  dynamically  and  incrementally  extended,  as  experiments  with  the  implementational 
or  theoretical  feasibility  of  new  ideas  fail  or  succeed. 

An  RLL  provides  these  same  sort  of  features  for  higher  level  representational  constructs: 

•  The  description  of  a  representation  is  accessible  via  the  same  mechanisms  (in  ARLO’s  case  the  ac¬ 
cessing  or  modification  of  values  in  slots  on  structures)  as  the  representation  itself;  indeed,  these  same 
mechanism.-  can  be  used  to  access  and  modify  ARLO's  description  of  the  language  ARLO! 
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•  Tools  built  for  describing,  examining,  or  massaging  a  given  representation  can  be  easily  generalized  to 
other  representations.  System  tools  —  used  for  describing,  defining,  and  modifying  representations  — 
can  be  just  as  easily  applied  to  the  structures  of  the  representation  as  to  the  representation  itself. 

•  The  definition  of  a  representation  —  since  it  is  stored  as  a  mutable  representation  itself  —  can  be 
dynamically  modified.  An  RLL  can  —  and  ARLO  generally  does  —  perform  the  appropriate  bookeeping 
to  diminish  unfortunate  or  fatal  repercussions  of  such  changes,  while  still  supporting  the  intent  of  the 
change. 

The  implementation  of  a  given  representation  or  program  takes  a  high  level  task  or  goal  and  reduces  it  to 
separately  implementable  parts.  An  RLL  provides  a  tool  kit  and  supply  closet  of  such  parts,  where  the 
interchangability  of  its  representational  components  makes  mechanism  or  experience  from  one  application 
transportable  to  another. 

1.1.2  RLL’s  as  Mediums  for  Programs  Which  Grow 

To  the  researcher  developing  intelligent  systems  which  grow  and  learn  by  themselves,  an  RLL  offers  a  way  to 
let  a  program  examine  and  extend  its  representation  and  understanding  of  a  domain.  The  same  properties 
of  an  RLL  which  support  design  efforts  of  human  expert  system  programmers  make  simpler  the  design  of 
mtchamcal  expert  system  programmers  which  design  and  debug  both  other  systems  and  themselves.  While  an 
RLL  does  not  neccessarily  embody  any  fundamentally  new  learning  or  problem  solving  technology,  it  does 
provide  a  framework  for  describing  such  technologies  generically  and  reflectively  (so  that  any  sufficiently 
general  mechanism  can  be  effectively  applied  to  its  own  description). 

For  any  level  in  an  RLL-based  system  —  described  problem,  specified  language,  or  the  RLL  itself  — 
the  same  mechanisms  for  accessing  and  modifying  its  description  are  available.  Due  to  this  homogeneity  of 
representation,  faculties  and  tools  built  to  operate  on  a  given  level  may  be  applicable  to  other  levels  in  the 
system  as  well.  Lenat’s  Eurisko  (Len83]  system  applies  the  discovery  mechanism  pioneered  in  AM  |Len82) 
to  such  diverse  domains  as  three  dimensional  VLSI  design,  space  gaming  fleet  design,  and  number  theory. 
But  since  the  discovery  mechanism  —  largely  a  collection  of  eclectic  generation  heuristics  —  operates  in 
and  is  described  in  an  RLL,  it  can  be  applied  to  itself,  improving  its  behaviour  with  the  accumulation  of 
“experience”  and  examples  in  the  application  of  heuristics.1 

Analytic  and  descriptive  tools  developed  in  an  RLL  can  generate  summaries  and  descriptions  of  im¬ 
plemented  or  evolved  systems  which  are  useful  to  both  human  and  mechanical  programmers  modifying  or 
extending  them.  Further,  since  developments  in  the  RLL  are  generally  extensions  or  modifications  of  exist¬ 
ing  structure,  descriptive  and  manipulative  mechanisms  and  metaphors  may  be  automatically  extended  to 
new  applications  in  new  domains.  For  instance,  the  grammar  and  dictionary  of  a  natural  language  interface 
might  be  automatically  extended  to  cover  newly  developed  or  assimilated  concepts  or  relations,  growing  by 
extensions  based  on  those  concept’s  derived  semantics.  Such  an  extensible  language  interface  would  explain 
newly  constructed  or  proposed  concepts  by  using  terms  and  grammatical  forms  extracted  from  the  com¬ 
ponents  which  the  concepts  were  developed  from.  In  the  same  manner,  the  operations  and  presentations 

M'nfirtunately.  Eurisko’s  experience  is  primarily  embodied  in  1  lit-  numeric  vi.r th?  assigned  tv  its  synthesized  r 
a  j-ri.  ri  heuristics.  We  might  wish  for  a  more  symbolic  description  of  the  systems  failures  and  successes  as  the 
t>a-i-  f  r  th':-  reflective  im  difie.at  j.  n. 
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offered  by  a  graphical  interface  might  be  automatically  extended  to  concepts  and  relations  barely  anticipated 
in  the  interface’s  conception.  The  interpretation  of  what  some  generic  operation  (characterized  perhaps  by  a 
particular  gesture  or  vocalization  to  the  interface)  on  an  object  should  do  may  be  derived  from  the  system’s 
description  of  it  and  of  that  description’s  underlying  semantics.  An  interface  which  represents  what  it  is 
interfacing  to  regularizes  the  user’s  access  to  a  changing  program,  making  the  implementation  and  debugging 
of  self-developing  systems  —  programs  which  grow  —  an  easier  task. 

1.2  Representation  as  Inference 

Before  leaping  into  the  question  of  how  representations  may  be  represented,  we  may  wish  to  characterize 
exactly  what  we  mean  by  representation.  While  we  probably  won’t  find  —  and  perhaps  don’t  desire  —  a 
complete  definition,  we  would  like  some  sort  of  intuitive  grasp  of  what  an  RLL  should  —  and  shouldn’t  — 
try  to  represent.  This  section  presents  a  characterization  of  representation  as  a  special  sort  of  inference,  and 
briefly  treats  the  consequences  of  this  characterization. 

1.2.1  Spontaneous  and  Deliberated  Inference 

In  the  beginning  of  this  chapter,  we  slipped  from  describing  A1  programs  to  describing  representation  lan¬ 
guages.  But  it  would  be  hopelessly  naive  to  claim  that  an  AI  program  is  merely  its  representation;  what 
issues  have  we  glossed  over  in  sharpening  of  our  focus  to  representation?  Which  part  of  what  Al  programs 
do  is  representation  and  which  parts  are  something  else? 

Many,  and  perhaps  most,  of  the  actions  of  an  AI  program  actively  solving  problems  or  operating  in 
some  particular  domain  (including  itself)  can  be  classed  as  inferences  connecting  one  partial  description  of 
the  world  to  an  extension  of  that  description.  Such  inferential  actions  further  seem  to  fall  into  fairly  distinct 
classes:  spontaneous  inferences  and  deliberated  inferences.  Spontaneous  inferences  are  the  sorts  of 
inferences  generally  described  with  terms  like  inheritance  or  defaulting,  while  deliberated  inferences  are  those 
inferences  to  which  we  apply  terms  like  hypothesis  or  counterexample.  This  distinction  between  spontaneous 
and  deliberat  ed  inference  is  one  made  by  nearly  all  AI  programs,  but  is  it  merely  an  implement  at  ional 
distinction,  01  is  there  a  deeper  semantic  motivation  behind  it? 

Certainly  there  is  no  such  distinction  implicit  in  the  product  of  such  inferences;  spontaneous  and  delib¬ 
erated  in'erences  seem  to  share  an  identical  character  of  belief  or  rational  integration.  The  difference  instead 
lies  in  the  act  of  inference  itself,  in  the  character  of  the  action  by  which  we  extend  our  representations  of 
the  world.  If  we  characterize  inferences  as  mental  actions,  spontaneous  inferences  might  be  looked  at  as  the 
basic  actions  of  a  rational  agent  making  inferences.  This  introspective  notion  places  a  psychological ,  rather 
than  semantic,  motivation  behind  the  distinction  between  spontaneous  and  deliberated  inferences.  While 
a  formal  analysis  of  any  given  inference  system  ntay  best  treat  the  two  sorts  of  inference  identically,  any 
implementation  or  psychological  theory  must  retain  the  division. 

1.2.2  Characterizing  Spontaneous  Inference 

Are  there  other  characteristics  —  besides  the  intuitive  and  psychological  characterizations  presented  above 
for  the  distinction  between  spontaneous  and  deliberated  inferences?  One  important  clarification  is  that 
tin-  distinction  is  not  identical  to  the  psychological  distinction  between  conscious  and  unconscious  mental 
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activities.  Conscious  and  unconscious  activities  each  involve  both  sorts  of  inference;  conscious  reasoning 
might  be  those  deliberated  inferences  which  are  verbalizable,  but  even  this  may  be  going  too  far.  In  any 
event,  spontaneous  inference  is  not  psychologically  subconscious  activity;  the  knowledge  that  Clyde  the 
elephant  is  gray,  while  a  spontaneous  inference,  is  certainly  not  a  “subconscious”  inference. 

One  distinction  which  we  might  make  between  these  two  sorts  of  inference  is  that  spontaneous  inference 
never  builds  large  mental  structures.  If  we  believe  that  there  are  aggregated  collections  of  ideas  in  the  mind 
—  structures  —  then  spontaneous  inferences  may  complete,  fullfill,  or  verify  these  structures,  but  will  never 
construct  them  ex  nthilo.  Deliberated  inference,  on  the  other  hand,  has  no  such  restriction;  indeed,  a  large 
part  of  its  operation  is  the  construction  of  just  such  loci  of  assumption  and  assertion. 

Our  names  for  the  two  sorts  of  inferences  suggest  another  distinction  which  we  should  clarify.  The  ad¬ 
jective  spontaneous  suggests  that  such  inferences  happen  quickly,  while  deliberated  suggests  a  more  extended 
process.  While  this  is  largely  the  intuition  intended,  we  need  to  make  clear  when  this  inferential  interval 
actually  occurs.  Both  spontaneous  and  deliberated  inferences  occur  on  demand ;  this  demand  may  be  of 
physical  neccessity  or  psychological  intention,  but  the  terms  spontaneous  and  deliberated  characterize  these 
inferences  as  actions  carried  out  on  demand,  rather  than  as  valid  possibilities  of  action  in  a  represented  world. 
Spontaneous  —  in  our  usage  —  does  not  mean  that  when  I  tell  you  Clyde  is  an  Elephant  you  automatically 
infer  that  he  is  gray.  It  does  mean  that  if  I  rsk  you  what  color  Clyde  is  you  can  tell  me  quickly,  without 
needing  to  go  through  any  complicated  intellectual  machinations. 

1.2.3  The  Evolution  of  Spontaneous  Inferences 


Does  deliberated  inference  become  spontaneous  over  time?  Is  the  distinction  the  same  as  the  mechanomorphic 
distinction  proposed  between  “compiled”  and  “interpreted”  knowledge?  Without  a  more  precise  definition 
of  such  “compilation”,  it  is  hard  to  decide  this  latter  question  one  way  or  another,  but  1  suspect  the  answer 
will  be  no.  The  process  of  compilation  —  as  generally  described  in  modern  computer  science  —  allows 
programs  to  run  faster  by  removing  general  character  and  making  assumptions  of  context  and  reference. 
Spontaneous  inference  does  not  rest  on  local  assumptions  of  context  or  reference,  as  its  execution  may  reach 
across  expanses  of  representation  and  structure.  Taking  the  point  about  mental  structures  offered  above, 
spontaneous  inferences  are  “fast”  because  they  do  not  need  to  generate  or  access  intermediate  structure 
created  on  the  fly. 

On  the  other  hand,  the  answer  to  the  first  question  above  —  about  deliberated  inference  becoming 
spontaneous  —  is  probably  affirmative.  The  way  deliberated  inference  becomes  spontaneous  involves  the 
change  of  representation ;  deliberated  inference  in  new  domains  works  with  structures  formally  representing 
the  domain  and  its  principles  —  the  manipulative  principles  of  algebra  or  the  force-motion  axioms  of  hitting 
baseballs;  with  time,  however,  the  representation  for  the  problem  becomes  specialized,  ns  individual  objects 
and  subproblems  are  placed  in  broad  and  powerful  classes.  It  is  by  this  process  that  deliberated  inference 
—  referring  to  objects  and  general  rules  —  becomse  spontaneous  inference  —  referring  to  properties  and 
particular  paradigms. 

Finally  returning  to  the  topic  at  hand,  an  RLL  is  a  lanagnage  for  describing  and  implementing  spon¬ 
taneous  inference  systems.  The  classification  of  inferences  as  spontaneous  does  not  exempt  them  from  the 
restrictions  we  typically  place  on  inferences.  We  still  can  demand  consistency,  account  ability,  and  robust 
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non-monotonicity.  As  such  it  must  offer  facilities  for  maintaining  what  we  demand  from  inferences  with  a 
minumuni  cost  in  their  execution. 

1.3  What  is  ARLO? 

As  suggested  in  the  previous  sections,  ARLO  embodies  a  theory  of  how  representation  languages  work. 
But  like  any  theory  tied  to  an  implementation,  ARLO’s  carries  its  baggage  of  prejudices,  leanings,  and 
restrictions.  Most  obviously,  ARLO  is  prejudiced  by  an  initial  configuration  as  a  frame-based  language. 
As  initially  configured,  ARLO  is  a  language  for  constructing  data-structures  —  objects  with  properties  — 
which  describe  the  operation  and  performance  of  other  representation  languages  also  based  largely  on  data- 
structures.  In  turn,  ARLO  is  itself  described  by  its  own  data-structures  and  this  description  is  referred  to  in 
compiling  and  interpreting  the  descriptions  of  representations  described  in  ARLO.  ARLO’s  compilation  and 
description  of  a  given  representation  references  the  in-core  structures  which  define  ARLO  itself,  rather  than 
being  hardwired  as  LISP  procedures.  In  compiling  a  given  representation,  ARLO  is  partially  interpreting 
its  own  description  of  itself. 

How  can  such  a  self-referential  interpretation  process  ever  run  efficiently?  ARLO  compiles  the  repre¬ 
sentations  it  describes  —  including  itself  —  into  LISP  code  cached  in  quickly  accessible  locations  in  the 
language’s  description.  This  caching  of  values  allows  ARLO  and  representations  described  in  it  to  run  effi¬ 
ciently  once  compiled.  A  value  dependency  mechanism 2  assures  the  accuracy  of  ARLO’s  cached  compilations 
by  updating  or  retracting  them  when  the  descriptions  from  which  they  were  compiled  are  changed.  Because 
of  this  bookkeeping,  representations  described  in  ARLO  —  including  ARLO  itself  —  can  be  dynamically 
modified  with  relative  impunity. 

Greiner  and  Lenat’s  RLL-1  is  cast  as  a  representational  “organ.”  whose  stops  and  settings  can  be 
modified  by  a  performer  or  user,  mutating  RLL-1  into  a  language  with  some  set  of  particularly  desired 
features.  ARLO,  while  supporting  this  sort  of  fundamental  mutation  by  providing  access  to  its  representation 
of  itself,  is  primarily  designed  to  support  extension  into  new  representational  paradigms,  without  supplanting 
its  basic  core.  Instead  of  an  organ,  ARLO  might  better  be  perceived  as  a  factory  of  synthesizer  components 
and  patches,  from  which  a  user  constructs  whatever  representational  tools  or  paradigms  she  will. 

The  ability  to  mutate  ARLO  and  languages  described  in  it  means  that,  in  some  ultimate  sense,  ARLO 
is  not  really  restricted  by  its  intinl  configuration;  ARLO  could  be  used  to  define  another  RLL  based  on 
assertions  rather  than  frame-like  data-structures.  Such  a  representation,  however,  might  not  be  acceptably 
efficient  because  of  the  way  ARLO  compiles  its  descriptions:  the  way  a  frame  system  is  compiled  and 
optimized  is  very  different  from  the  way  an  assertion  based  language  would  be  compiled  and  optimized. 
ARLO  could  be  radically  mutated  to  do  such  optimizations,  but  1  certainly  don’t  claim  to  have  done  this, 
and  in  some  strong  sense  such  an  accomplishment  would  be  a  wholly  different  language 

*A  value  dependency  mechanism  i-  a  generalizatin  vf  pr  -p-siti-rial  dependency  mechanisms  like  D«. y77  or  McA7« 
It  keeps  track  of  what  elements  ..f  the  environment  ..  given  environmental  side  effect  depends  -  n.  updating  -.-r 
undoing  that  side  effect  when  those  elements  are  changed.  A  prepositional  TMS  is  a  specialized  sort  value  de¬ 
pendency  «y«ttni  which  perforins  this  uiaintenaiiri  fun.  li  m  -vei  just  the  truth  values  f  run-  and  pr-p-siti  n-. 
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1.4  Basic  Concepts:  A  User’s  Introduction 

ARLO  is  a  frame  based  language. 

A  new  user  approaching  ARLO  in  its  initial  configuration  finds  a  classical  “frame  based"  language  much  like 
FRL  [RG77]  or  UNITS  |Ste79],  In  this  language,  she  may  create,  examine  and  manipulate  data  structures  — 
called  units  —  which  possess  properties  —  called  slots  —  to  which  are  attached  values  —  which  are  lisp 
objects  of  various  sorts.  Each  ARLO  unit  has  a  unique  name  relative  to  some  knowledge  base  (a  namespace 
grouping  many  related  units  together),  and  its  slots  map  symbolic  names  —  each  again  relative  to  some 
particular  knowledge  base  —  to  single  values.  As  in  other  frame  based  languages,  the  value  of  a  slot  is 
i  sometimes  computed  on  demand;  a  slot’s  attempted  retrieval  may  compute  a  value  (a  default)  for  the  slot  if 

one  is  not  already  available. 

Defaulted  values  are  cached  and  justified. 

When  the  value  of  a  slot  of  some  ARLO  unit  is  defaulted,  the  newly  computed  default  is  saved  —  cached 
—  on  the  unit  itself.  This  caching  allows  subsequent  references  to  the  slot  to  return  a  value  immediately, 
without  having  to  recompute  a  default  value.  Each  of  these  cached  values  also  records  the  justifications  of 
its  derivation:  the  function  used  to  compute  it  and  the  slots  referenced  in  its  computation.  When  the  user 
later  changes  one  of  these  supporting  justifications,  she  finds  that  the  cached  default  —  typically  listed  when 
the  unit  is  described  to  her  —  disappears.  When  she  asks  again  for  its  value,  a  new  up-to-date  default  is 
computed,  and  once  more  cached  on  the  unit.  The  justifications  of  each  of  these  defaulted  slots  are  explicitly 
available  to  the  user:  when  she  asks  for  a  description  of  some  particular  slot’s  value,  its  justifications  are 
listed  along  with  the  description  of  its  value 

Different  slots  have  different  semantics. 

From  the  justifications  ascribed  to  various  slots,  our  user  discovers  that  different  slots  derive  their  defaults  in 
different  ways.  For  instance,  she  finds  that  the  Telephone-number  slot  of  a  person-description  defaults  through 
its  Organization  slot,  while  the  description’s  Home-Addreaa  slot  defaults  through  the  Spouse-Equivalent  slot 
attached  to  it.  Further,  in  the  process  of  creating  and  modifying  various  units,  she  finds  that  certain  slots 
will  accept  only  certain  types  of  values  and  will  attach  to  only  certain  kinds  of  units.  The  Supervisor  slot  of  a 
person-description  -  for  instance  accepts  only  other  person-descriptions  (determined  by  some  inheritance 
criterion  in  some  hierarchy)  for  it-  values  and  attachments.3  When  she  accesses  ARLO’s  descriptions  directly 
from  LISP  (using  a  small  repefoire  of  top  level  functions  for  accessing  and  storing  values  in  slots)  the  user 
discovers  that  the  way  in  which  slot  values  are  printed  and  described  also  varies  from  slot  to  slot,  a  Birthdate 
slot  may  store  its  value  a-  a  number  in  seconds  since  1000,  but  this  value  is  always  printed  out  in  a  more 
human-palatable  form.  Different  slots  in  ARL<>.  she  concludes,  have  different  semantics:  different  sensible 
values  and  attachments,  different  mechanisms  bn  defaulting,  differe  nt  methods  foi  describing  their  values, 
etc. 

These  semantics  are  explicitly  described  in  ARLO. 

3T)ie  attachment  of  a  «!■■(  is  the  unit  it  att.'ulie.-  c.iiu*  ’  I  ;  tie  Home  Address  si-  t  f  tin  unit  Kns-Knng'.s.  its 

attachment  is  tin-  unit  Kris  Knngle  ai.-l  c  . :•  -  "N  'll  -  I  , 
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Wlien  at  some  point  our  user  wishes  to  know  more  about  the  semantics  of  a  particular  slot,  ARLO  reveals 
its  accessible  underside.  To  get  a  description  of  a  particular  sort  of  slot,  she  need  only  examine  an  ARLO 
unit  describing  the  slot  to  see  a  summary  of  its  intentions,  mechanisms,  and  restrictions  as  specified  by  its 
human  or  mechanical  implementor.  Each  slot  in  AHLO.  she  discovers,  is  described  by  an  ARLO  unit.  For 
example,  if  she  wants  to  use  a  “color”  slot  defined  by  some  other  user,  she  can  describe  the  the  slot-defining 
unit  named  COLOR  to  see  its  complete  specification.  This  COLOR  unit  details  many  aspects  of  the  “color”  slot: 
what  types  of  objects  can  be  stored  as  colors,  which  sorts  of  units  may  have  colors  attached  to  them,  how  a 
color  should  be  described  to  a  user  or  even  precompiled  problem  solving  “cliches”  for  discovering  or  changing 
the  color  of  an  object. 

Modifying  this  description  can  alter  the  semantics  of  the  language. 

But  these  descriptions  are  not  merely  one-way  windows  on  the  semantics  of  the  language;  if  the  user  is 
dissatisfied  with  some  part  of  the  definition  of  the  slot,  she  can  modify  the  ARLO  unit  describing  it  and  that 
its  semantics  have  changed.  For  instance,  having  the  definition  of  the  color  slot  “in  hand,”  she  can  extend  or 
modify  different  aspects  of  its  semantics  —  such  as  how  it  is  defaulted,  restricted,  or  described  —  by  using 
established  and  familiar  functions  and  utilities  for  modifying  ARLO  units. 

ARLO  represents  implementation  as  well  as  semantics. 

The  ARLO  description  of  a  slot  specifies  not  only  its  semantics  —  its  restrictions  and  assumptions  —  it. 
also  specifies  its  implementation.  Since  the  methods  for  storing  or  fetching  the  value  of  a  slot  are  explicitly 
described  in  ARLO,  different  slots  may  be  implemented  in  different  ways.  For  instance,  some  slots  might 
store  their  values  in  a  high  speed  “connection  memory”  [Hil85|,  while  others  might  store  their  contents  on 
a  shared  storage  device  across  a  local  network.  While  the  initial  ARLO  configuration  uses  only  immediate 
storage  techniques  (storing  values  directly  on  the  unit  data  structure),  this  in  no  way  limits  its  ultimate 
configuration  or  organization. 

ARLO  also  represents  its  own  semantics  and  implementation. 

ARLO  represents  not  only  other  representation  systems,  it  also  represents  itself.  The  slots  and  units  used  to 
describe  the  semantics  of  a  given  representation  are  themselves  described  in  ARLO.  This  means  that  the  unit 
describing  the  To-Verify-Type  slot  4  lias  a  To-Verif y-Type  slot  which  is  referred  to  whenever  a  To-Verify-Type 
property  is  defined  for  a  slot. 

AHLO’s  self-representation  is  made  possible  by  an  elaborate  and  circumvent ive  bootstrapping  process 
that  occurs  when  it  is  compiled  and  loaded.  In  this  process,  slot-describing  slots  —  such  as  To-Get-Value 
or  To-Venf y-Type  —  are  defined  as  units  with  preemptively  stored  To-Get-Value  or  To-Verify-Type  slots 
referenced  by  run-time  ARLO.  ARLO’s  bootstrapping  process  sneaks  around  the  self-referential  interpre¬ 
tation  mechanism  to  prepare  a  pre-compiled  runtime  environment  which  refers  to  itself  ill  compiling  and 
interpreting  other  representation  languages,  including  the  remainder  of  itself. 

The  ability  of  ARLO  to  easily  modify  itself  allows  introspective  activities  like  self-modification,  self- 

4The  To-V«rify- Type  slot  stores  the  function  which  a  sh  t  uses  determine  if  a  given  value  and  attached  unit  are 

■ic  replable. 
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documentation,5  or  self-explanation  to  be  performed  with  ARLO  structures.  Not  only  may  a  program 
written  in  ARLO  examine  or  modify  its  own  representation  language,  it  may  examine,  extend,  and  modify 
(within  limits)  the  language  in  which  that  representation  language  is  described. 


5For  instance,  the  documentation  in  the  appendices  was  produced  by  ARLO  examining  and  describing  its  own 
description. 
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Most  Al  languages  are  implementation  towers;  it  is  popular  to  diagram  the  construction  of  a  given  A1  pro¬ 
gram  as  a  tiered  construction  of  implementation  layers  resting  on  a  foundation  of  vanilla  LISP.  (Occasionaly 
some  clever  wag  also  sketches  in  the  machine  language,  microcode,  logic  circuitry,  and  semiconductor  physics 
beneath  this  LISP  foundation.)  Figure  2-1  is  such  a  diagram  for  ARLO’s  construction,  illustrating  the  foun¬ 
dational  role  each  level  plays  in  the  next.  This  chapter  describes  these  components  of  ARLO’s  implementation 
and  the  boostrapping  process  which  consolidates  them  into  a  working  self-referential  implementation. 


Figure  2-1.  The  Layered  Implementation  :.f  ARLO 
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But  Figure  2-1  is  not  quite  the  typical  “layers  of  implementation’’  diagram,  its  del  ails  offer  inmr  .  -  ni*-iii  i  I,  u, 
simply  illustrating  levels  of  embedded  languages.  The  horizontal  arrows  on  the  figure  mdu  aie  t».  nn|>..|i  .mi 

phases  of  ARLO’s  deployment;  each  corresponds  to  the  boostrapping  of  some  mini . .  of  Alt  I  <  »  -•-It 

representation.  The  first  bootstrap  is  the  definition  of  ARLO  as  a  representation  defining  laug'iiv  !  I. . 
second  boostrap  is  the  completion  of  ARLO’s  type  restriction  system,  which  constrain-  the  calm--  m  l 
attachments  of  various  slots. 

As  intimated  above,  a  language  implemented  in  ARLO  remains  reasonably  efhc  ent  b\  <  aching  n-  <  in- 

piled  implementation  on  quickly  accessible  properties  of  its  description  We  might  view  this  . . pilau-  n 

process  as  pushing  ARLO’s  execution  down  the  tower  of  Figure  2-1.  While  a  given  representation  i-  -.In¬ 
scribed  at  the  level  just  above  ARLO’s  definition,  it  is  implemented  and  executed  at  the  more  eth-  i-  nt  level- 
below  it. 

The  tower  in  Figure  2-1  has  11  distinct  components,  each  of  which  plays  a  foundational  role  in  t  In- 
components  above  it: 

1.  The  LISP  underpinning 

ARLO  is  implemented  in  LISP  Machine  LISP  'WM82'  for  a  variety  of  special  purpose  LISP  Machines 
The  version  of  ARLO  described  here  is  ARLO  Version  25.30.  running  in  Symbolics  Release  5  2  ARLO 
uses  a  variety  of  facilities  developed  for  the  LISP  Machine,  providing  (among  other  caparitie-)  special 
capabilities  for  formatted  output  and  “impatient  i/o”. 

2  UNITS:  A  Data  Structure  Facility 

LISP  is  used  to  implement  a  data-structure  facility  for  creating  and  accessing  named  objects  with  named 
properties.  These  structures  —  called  units  after  RLL  —  are  implemented  as  fixed-length  hash  tables 
which  pair  symbolic  names  to  single  values  (which  may  of  course  describe  sets  of  values).  The  names 
of  units  and  slots  are  organized  by  a  namespace  system  which  divides  units  into  knowledge  bases; 
particularly,  a  knowledge  base  provides  a  many-to-one  mapping  from  symbolic  names  to  unit  struct  tires. 
3.  The  Value  Dependency  Mechanism 

Also  implemented  in  LISP  —  or  precisely,  in  Lisp  Machine  flavors  —  is  a  value  dependency  mechanism 
for  keeping  track  of  dependencies  between  various  properties  and  bindings  of  the  LISP  environment, 
particularly  the  values  assigned  to  the  slots  of  ARLO  units.  This  mechanism  is  used  by  a  deployed 
ARLO  to  keep  track  of  its  changing  defaults  as  well  as  its  changing  semantic  definition.  The  value 
dependency  mechanism  is  described  in  Section  2.2. 

4  The  Error  Facility 

No  large  system  is  perfectly  bug-free,  and  ARLO’s  self-referential  implementation  makes  catching  and 
dealing  with  its  internal  problems  a  tricky  task.  Tracking  and  repairing  an  internal  ARLO  hug  is  often 
like  trying  to  climb  out  of  a  sand  pit;  each  exploratory  modificat ion  may  shift  or  shatter  t he  foundat ions 
beneath  you.  Despite  this,  ARLO  retains  a  degree  of  robustness  through  two  mechanisms:  the  first  is 
the  value  dependency  mechanism  which  ensures  that  changes  in  mechanisms  described  in  ARLO  from 
component  to  component  in  the  implementation;  the  second  is  a  rich  taxonomy  of  errors  and  conditions 
which  are  signalled  when  ARLO  detects  itself  going  wrong.  These  errors  describe  conditions  such  as 
obviously  fatal  recursions,  type  conflicts,  or  violations  of  bootstrap  requirements.  ARLO’s  facilities  for 
handling  and  signalling  these  unusual  conditions  is  described  in  Section  2.3. 
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5  Reflexive  Operators 

-  ARLO’s  self-reference  is  centrally  embodied  in  a  mechanism  called  reflexive  operators.  Reflexive  oper¬ 
ators  refer  to  ARLO  unit  structure  to  determine  how  to  operate  on  and  access  other  unit  structures. 
When  the  description  of  an  embedded  language  (or  of  ARLO  itself)  is  compiled,  it  is  assembled  into  a 
set  of  units  whose  interpretation  by  reflexive  operators  fullfills  the  intended  semantics  of  the  langauge’s 
description.  Reflexive  operators  are  an  interpreter  for  frame  like  data-structure  languages;  the  ARLO 
language  itself  (interpreted  by  these  mechanisms)  is  a  compiler  for  turning  high  level  representation 
descriptions  into  structures  for  this  interpretation  process. 

<>  ARLO’s  Definition 

These  are  the  units  which  define  ARLO’s  core,  specifying  a  language  —  interpreted  by  reflexive  operators 
—  which  describes  how  the  slots  of  a  frame-based  representation  language  default,  restrict,  and  describe. 
The  detail  of  Figure  2-1  illustrates  how  the  definition  of  these  central  units,  skirting  ARLO’s  self- reference 
mechanism,  extends  below  the  level  of  reflexive  operators  at  ARLO’s  first  boostrap.  The  essentials  of 
ARLO’s  definition  —  how  it  describes  and  defines  the  slots  of  various  representations  —  are  documented 
in  Section  2.5. 

7.  The  ARLO  coder 

ARLO’s  ability  to  define  representation  languages  is  used  immediately  in  implementing  ARLO’s  coder 
-  mechanism,  specifying  a  language  for  describing  the  implementation  of  LISP  functions.  ARLO’s  coders 
expand  partial  descriptions  of  common  representation  functions  (inheritance,  composition,  type  restric¬ 
tion,  etc)  into  completely  specified  LISP  implementations.  These  tools  for  function-building  are  detailed 
in  Section  2.6. 

8.  The  TYPE  system 

On  top  of  the  coder  mechanism,  ARLO’s  type  system  is  implemented.  The  type  system  implements 
a  non-excepting  generalization  hierarchy  for  predicates;  these  are  used  to  specify  restrictions  on  the 
attachments  and  values  of  slots  defined  in  ARLO.  ARLO’s  own  initial  description  (which  is  used  to 
implement  this  hierarchy  of  types)  refers  to  the  type  system  by  referencing  the  names  of  particular 
types.  The  bootstrapping  of  the  type  system  (the  second  dotted  line  on  Figure  2-1)  maps  over  every 
unit  in  ARLO’s  description  of  itself  and  replaces  all  of  its  symbolic  type  names  with  now-assembled 
type  descriptions.  ARLO's  utility  package  extends  the  type  system  into  a  class  system  for  organizing 
units  into  overlapping  description  categories  to  which  particular  methods  and  heuristics  are  attached. 
The  basic  form  of  the  type  system  is  detailed  in  Section  2.7. 

9.  Archives  and  Layers 

A  representation  language  language  allows  a  complicated  program  and  representation  to  be  extended  (or 
to  extend  itself)  over  time;  but  if  the  program  must  be  rebooted  and  restarted  each  morning,  its  scope  is 
limited  by  its  short  lifetime  Archives  and  layers  are  a  mechanism  for  wholly  and  incrementally  dumping 
ARLO  represent ations  and  descriptions.  The  knowledge  of  a  sophisticated  program  is  a  dynamic  and 
inlet  connected  network  of  descriptions:  archives  and  layers  are  tools  for  preserving  those  networks  be¬ 
tween  sessions  and  even  (if  any  projects  are  sharing  particular  representational  tools)  between  domains 
The  implementation  of  archives  and  layers  is  documented  in  Section  2.8. 

10.  The  User  Interface 
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In  the  previous  chapter,  one  of  our  arguments  for  the  utility  of  RLLs  was  the  expressive  flexibility  they 
might  bring  to  a  user  interface.  ARLO’s  user  interface  explicitly  accesses  and  refers  to  the  semantic 
description  of  the  descriptions  it  is  presenting,  offering  different  displays  and  options  based  on  the  under¬ 
lying  definition  of  what  it  is  describing.  ARLO’s  interface  —  operating  through  a  variety  of  “interface 
modes”  —  determines  its  presentations  and  presumptions  by  its  own  description  of  the  concepts  and 
relations  it  is  presenting. 

11.  Embedded  Languages 

Languages  embedded  in  ARLO  are  finally  built  on  the  top  of  this  edifice,  taking  advantage  of  the 
descriptive  and  debugging  facilities  beneath  them.  Many  representations  built  in  ARLO  (including 
extensions  of  ARLO  itself)  do  not  build  very  high  over  the  mechanisms  which  ARLO  natively  uses  to 
describe  representation  languages.  These  mechanisms  —  simple  property  inheritance,  single  hierarchy 
type  restrictions,  etc  —  may  be  all  a  user  needs  for  her  application;  but  on  the  other  hand,  she  may 
easily  implement  more  complicated  representational  constructs  and  abstractions  at  need. 

2.1  Units  and  Knowledge  Bases 

Units  are  LISP  structures  which  map  named  properties  to  LISP  objects.  Implemented  as  fixed  length  hash 
tables,  they  can  be  thought  of  as  a  fast  implementation  of  property  lists.  The  implementation  of  units  imposes 
no  semantic  restrictions  on  what  may  be  represented,  outside  of  presuming  that  their  exist  objects  witli  named 
properties.  The  semantics  of  ARLO  comes  from  the  interpretation  of  descriptions  constructed  from  these 
units,  much  as  the  semantics  of  LISP  comes  —  in  a  sometimes  illusory  sense  —  from  the  interpretation  of  list 
structures.  ARLO’s  units  —  like  LISP’s  global  function  and  variable  definitions  —  are  more  or  less  global 
definitions,  but  they  are  organized  into  many  separate  distinct  knowledge  bases. 

Each  ARLO  unit  has  a  name  and  is  attached  to  a  particular  knowledge  base,  which  is  a  structure 
containing  a  collection  of  related  units.6  Within  this  knowledge  base,  the  unit’s  name  is  unique,  though  it 
may  possess  other  aliases  in  the  same  or  different  knowledge  bases.  To  support  this,  each  knowledge  base 
provides  a  many  to  one  mapping  from  names  to  units;  but  for  each  unit,  one  of  these  mappings  is  it’s  unique 
(rue-name  used  (by  default)  in  printing  and  archiving  it. 

A  unit’s  printed  representation  looks  like  this: 

{#>explai::  sub-divisiq::s) 

where  SUB-DIVlSIO!iS  is  the  name  of  a  unit  in  the  EXPLAI'I  knowledge  base.  A  user  refers  to  a  unit  in  a  given 
knowledge  base  by  using  the  lisp  reader  macro  “#>”.  For  example,  the  expression  {#>E.Y.PLAU  SUB-DIVISIDXS) 
refers  to  the  unit  whose  printed  representation  appeared  above. 

ARLO’s  knowledge  bases  are  arranged  in  a  hierarchy  from  the  root  CORE  knowledge  base,  as  pictured 
in  Figure  2-2.  All  units  defined  in  a  knowledge  base  are  also  defined  in  the  knowledge  bases  below  it.  For 
instance,  every  knowledge  base  contains  the  units  of  the  CORE  knowledge  base;  similarly,  all  of  the  units 
defined  in  the  EXPLAIN  knowledge  base  will  be  defined  in  the  THESIS  knowledge  base  beneath  it.  Knowledge 
bases  are  a  namespace  mechanism  and  not  a  real  “representational  context”  mechanism;  user  code  cannot 
easily  refer  to  “X  m  the  current  context,"  but  only  to  “X  in  the  EXPLAIN  context”. 

‘'Knowledge  base?  are  implemented  on  top  of  the  Common  LISP  package  system,  a  facility  for  maintaining  mult i- 
j  a  n..m<  spaces  in  a  -ingle  LISP  envircnmont 
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Figure  2-2.  ARLO’s  knowledge  bases  are  organised  into  a  hierarchy  of  name  inheritance. 

2.2  The  Value  Dependency  Mechanism 

ARLO’s  slots  are  interconnected  with  a  value  dependency  mechanism.  When  the  value  of  a  slot  is  defaulted 
and  cached,  a  dependency -record  for  the  value  is  created  referring  to  the  dependency  records  of  the  values 
accessed  in  computing  the  cached  default.  Each  of  these  referenced  dependency  records  is  also  given  an 
inverse  pointer  to  the  newly  created  dependency  record.  Later,  if  one  of  these  referenced  dependencies  —  an 
“assumption"  the  cached  default  depends  on  —  is  invalidated,  the  dependency  record  for  the  cached  value 
is  also  invalidated.  This  invalidation  decaches  the  out  of  date  default,  removing  it  from  the  unit  structure 
on  which  it  was  cached.  The  next  attempt  to  access  the  value  will  then  —  in  the  absence  of  a  cached  value 
—  be  forced  to  recompute  a  valid  value  for  the  slot. 

The  tracking  of  a  slot’s  dependencies  is  quite  simple.  When  a  slot  is  being  defaulted,  the  global  variable 
SLOT-BEi::G-DEFAULTED  is  bound  to  a  dependency  record  for  the  slot  being  defaulted  Every  slot  access 
occuring  during  the  computation  of  this  default  calls  the  form: 

(ASSUMING  unit  slot ) 

to  make  the  dependency  record  kept  in  SLOT-BEIilG-DEFAULTED  dependent  on  t  he  current  slot  of  unit.  This  de¬ 
pendency  tracking  may  be  disabled  by  the  macro  form  AS-A-SIDE-EFFECT,  which  binds  SLCT-BEI'.IG-DEFAULTED 
to  ;:il  for  the  dynamic  scope  of  its  body,  thus  protecting  any  default  computations  in  progress  from  depen¬ 
dence  on  slots  accessed  in  execution  of  its  body.  In  addition,  the  call  to  ASSUMING  is  part  of  each  slot’s 
description,  so  individual  slots  might  be  defined  to  not  reference  the  dependency  creating  form 

Dependency  records  for  slots  are  stored  in  a  noil-reflective  network  (i.e.  simply  as  named  propertie>  of 
unit  structures)  defined  in  special  knowledge  bases  associated  with  the  knowledge  base  of  the  slot’s  whose 
values  thev  describe.  For  instance,  the  dependencies  for  the  #>C0RE :  To-Def  aul t - Va lue  slot  are  stored  on 


ARLO 


Ken  H  arise 


the  #>CORE-DEPE!!DE'.'CIES  :  To- Default -Value  property  ( not  slot )  7  of  the  unit  whose  #>C0RE  :  To-Def  ault- 
Value  slot  they  describe.  A  given  slot’s  dependency  record  may  be  accessed  by  the  form, 
(get-dependency-record  unit  slot ) 

which  gets  the  dependency  record  describing  the  current  value  of  unit's  slot.  These  dependency  records  are 
implemented  as  flavor  instances  :Can83’  which  accept  messages  defining  an  invalidation,  justification,  and 
description  protocol. 

2.2.1  Dependency  Mechanism  Protocols 

ARLO'?  value  dependency  mechanism  uses  the  message  passing  facility  of  flavors  to  define  a  protocol  for 
the  propogation  of  slot-value  invalidation.  In  addition  to  this  role,  other  protocols  define  ways  of  recording 
justifications  (which  may  later  lead  to  invalidations)  and  documenting  or  describing  the  supports  of  an 
assumed  or  deposited  value.  These  protocols,  however,  never  refer  to  slots  or  units  in  particular  and  is  easily 
extended  beyond  this;  while  most  of  the  nodes  in  the  dependency  network  describe  the  values  of  slots,  many 
do  not.  Some,  for  instance,  describe  value  or  function  bindings  in  the  LISP  environment;  others  play  critical 
roles  in  the  presentation  —  to  the  user  —  of  the  slot  network. 

In  particular,  several  graphical  interfaces  to  ARLO  have  the  visual  presentations  of  ARLO  slot  bindings 
"wired  into"  the  dependency  network  running  between  slots;  the  appearance  of  a  given  presentation  in  the 
interface  then  change?  with  the  validity  of  the  slot  value  it  represents.  The  graphical  representation  a 
flavor  object  -  is  defined  to  handle  the  invalidation  protocol  for  dependency  records  and  then  connected 
into  the  active  dependency  network  just  like  any  othei  node. 

The  invalidation  and  justification  protocol  is  defined  by  six  messages  which  are  sent  to  and  passed  among 
nodes  in  the  dependency  network: 

•  :  I  r.VALIDATE-SELF  invalidates  a  given  dependency  record  and  the  dependency  records  which  depend  on 
it  This  is  generally  sent  by  an  outside  function,  rather  than  from  one  dependency  record  to  another. 

•  RETRACT -DEPENDENTS  invalidates  the  dependents  of  a  given  dependency  record.  It  does  this  by  sending 
ali  of  its  dependents  a  SUPPORT -RETRACTED  message  (with  itself  as  an  argument),  normally  causing  the 
dependent  value  to  be  undone  and  spinning  off  another  wave  of  SUPPORT-RETRACTED  messages. 

•  SUPPORT -RETRACTED  is  sent  to  a  dependency  record  when  one  of  the  dependency  records  it  depends  on  is 
invalidated  The  response  of  a  dependency  record  to  this  message  will  typically  go  and  alter  the  value 
or  assignment  to  which  the  dependency  record  refers.  (This  in  turn  will  typically  invalidate  the  node 
receiving  tin  message,  and  spin  off  new  RETRACT- DEPELDELTS  and  SUPPORT -RETRACTED  messages.) 

•  ADD- DEPEdDELT  adds  a  dependency  record  (its  single  argument)  to  the  records  dcptndid  on  by  the  record 
this  message  is  sent  to. 

•  RE::o\’E-DEPE:'DE:;T  remove-  a  dependency  record  (it?  single  argument)  from  the  records  depended  on  by 
the  record  this  message  is  sent  to. 

•  REPLACE-SELF  replaces  the  dependency  record  it  is  sent  to  with  a  new  dependency  record  (its  single 
argument)  In  order  to  side  effect  its  value,  the  dependency  record  which  receives  this  message  should 
know  where  the  value  it  refers  to  is  stoied. 

7T!ic  distia,  '  i  n  1  f-t  ween  a  ‘property’  and  a  ‘slot*  is  t  !.:,t  a  si  t  has  .m  ahsttuct  des-.  rip' i-  n  spe.  dying  the-  in'  *  r- 
pre'  it  'nii  i  . :  s*  in nt -  f  d  -  \  1 1  e  -  ■  r, ■  I  i  ' ; 1 1  perty '  is  simply  i  i,  i n u  .1  at  i  ril  u1 1  i.  t  ..uni: 
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Dependency  records  also  support  a  collection  of  messages  for  debugging  and  explanation  of  the  values  they 
represent.  There  are  four  basic  messages  for  describing  dependency  records: 

•  DESCR1BE-C0HTENT  describes  the  value  its  record  represents.  This  is  used  by  all  the  descripton  functions. 
This  description  is  sent  to  the  stream  which  is  the  messages  single  argument. 

•  DESCRIBE-HISTORY  describes  the  record  it  is  sent  to,  as  well  as  the  record  that  record  replaced,  thus 
producing  a  history  of  the  value  the  dependency  describes.  It  takes  a  stream  as  a  single  argument,  as 
above. 

•  DESCR1BE-DEPENDENTS  describes  the  other  dependency  records  which  depend  on  this  dependency  record. 
It  takes  a  stream  as  a  single  argument,  as  above. 

•  DESCRIBE- JUSTIFICATION  describes  where  this  value  came  from.  If  it  was  deposited  by  some  person, 
computed  from  some  other  slots,  etc. 

In  the  development  of  this  protocol,  it  was  neccessary  to  overcome  the  confusion  of  having  two  distinct  net¬ 
works:  the  unit-slot  network  and  the  dependency  network.  Early  versions  of  the  protocol  did  all  propogation 
of  invalidation  through  the  dependency  network,  causing  numerous  problems  with  slots  which  wished  to  avoid 
or  affect  their  invalidation  in  various  ways.  The  final  solution  was  the  separation  of  the  SUPPORT -RETRACTED 
and  RETRACT-DEPEI1DEUTS  messages  by  reference  to  the  unit-slot  network.  This  barrier  finally  allowed  the 
dependency  mechanism  to  avoid  enforcing  certain  semantics  on  the  unit-slot  network. 

ARLO’s  initial  configuration  defines  three  basic  sorts  of  dependency  records:  Slot-Computation-Recorda, 
Slot-Citation-Records,  and  Slot-Boot-Records.  Slot-Computat jon-Records  are  records  of  slot  computations 
(such  as  the  computation  of  a  default)  which  referred  toother  slots  and  can  be  invalidated  by  the  invalidation 
of  those  slots’  values.  Slot-Citation-Records  are  dependency  records  which  refer  to  a  particular  source  and 
attribution  responsible  for  them.  Typically  these  are  references  to  users  or  text  files.  Slot -Boot -Records 
describe  slots  defined  before  ARLO’s  critical  bootstrap  period;  attempting  to  invalidate  these  records  results 
in  a  proceedable  error.  This  warning  sometimes  avoids  fatal  self-modification  by  programs  in  ARLO  or 
unsuspecting  users. 

2.3  ARLO  Errors  and  Conditions 

ARLO  uses  the  lisp  machines’  condition  fysltm  |WeiS3]  to  define  a  taxonomy  of  conditions  with  which  it 
complains  when  it  comes  across  unexpected  or  unusual  situations.  These  conditions  include  both  external 
condition-  (such  as  a  particular  user  or  machine  not  responding  to  requests)  and  internal  conditions  (such  as 
fatal  recursions  or  type  conflicts).  Code  using  ARLO  may  anticipate  and  catch  these  conditions  and  there 
is  a  standard  facility  an  ARLO  coder  -  for  doing  this  preemptive  preparation.  Futher.  these  conditions 
are  defined  so  as  to  offer  standard  ways  to  proceed  from  various  situations  as  well  as  providing  pertinent 
information  to  the  tiset  when  she  is  asked  to  handle  the  condition  (typically  by  entrance  to  the  LISP  Machine 
debugger). 
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the  program  in  the  variable  SLOT-ACCESSES  .  ARLO  uses  this  dynamic  record  for,  among  other  purposes, 
identifying  when  it  is  fatally  recursing  on  some  slot  access.  8 

The  function  where  can  be  used  to  look  at  this  part  of  ARLO’s  current  dynamic  state:  It  produces  a 
trace  that  looks  like  this: 


ARLO  is  currently: 

4:  trying  to  compute  the  Supervisor  slot  of  {#>KYLE} 

3:  while  getting  the  Supervisor  slot  of  {#>KYLE} 

2:  while  trying  to  compute  the  Hacking  slot  of  {#>KYLE} 

1:  while  getting  the  Hacking  slot  of  {#>KYLE} 

If  you  use  the  debuggers  Contfol-M  command  to  send  a  bug  report  on  an  ARLO  condition,  a  version  of 
the  above  trace  is  included  in  the  bug  message.  In  addition,  you  can  type  the  keystroke  command  Cont/ol-? 
to  get  a  where  trace  while  in  the  debugger. 

2.3.1  Anticipating  errors 


ARLO’s  errors  signal  not  only  unexpected  conditions  —  such  as  type  conflicts  arising  from  sloppy  generated 
or  user  code  —  but  also  “unfortunate”  conditions  such  as  failed  searches  or  absent  users.  For  both  of  these, 
the  program  itself  might,  want  to  take  action  when  the  error  occurs.  In  the  case  of  unexpected  conditions 
(what  we  might  call  true  errors),  the  program  might  wish  to  repair  or  banish  a  definition  or  description;  in 
the  case  of  unfortunate  conditions,  the  program  might  wish  to  apply  another  method  or  simply  assume  a 
harmless  default.  Harnessing  the  Lisp  Machine’s  condition  handling  system,  ARLO  is  able  to  answer  both 
of  these  demands. 

Unfortunate  conditions  are  generally  conditions  of  failed  methods,  for  which  there  are  alternative  re¬ 
sponses  or  actions.  In  ARLO,  unfortunate  conditions  are  handled  by  “try  and  try  again”  functions,  which 
possess  many  distinct  methods  for  performing  their  computation,  moving  from  one  to  the  next  if  an  error 
occurs.  These  functions  are  typically  synthesized  by  ARLO  coders  2.6  such  as  the  METHODS  or  EXPECT  IMG 
coders  2.7  When  errors  occur  when  these  functions  are  executing,  they  throw  out  of  the  erring  method  and 
advance  to  another  or  signally  a  final  error  if  no  more  methods  exist. 

I  nexpected  conditions,  on  the  other  hand,  generally  arise  from  ill-formed  programs  or  descriptions; 
their  occurence  generally  demands  the  alteration  or  generation  of  relatively  large  programs  or  descriptions. 
As  such .  t  he  react  ion  to  such  errors  falls  into  t  lie  class  of  opera  l  ions  which  we  identified  in  1.2.1  as  deliberated 
inferences.  Here  we  perceive  i  powerful  pattern  to  the  interaction  of  spontaneous  and  deliberated  inferences: 
deliberated  inferences  arise  from  the  failure  of  spontaneous  inferences  It  is  only  when  our  cached,  compiled, 
and  common  methods  fail  that  we  turn  to  the  carefully  constructive  process  of  deliberation  in  our  problem 
solving.  We  must  at  least  -  if  we  wish  to  build  mind-like  systems  with  ARLO  -  provide  explicit  classes  of 
these  unexpected  conditions  which  reveal  precisely  how  the  languages  definition  and  description  have  been 


Blf  ARLO  is  about  to  perform  a  slot  access,  it  first  checks  that  it  is  not  already  (further  up  t lie  stack)  perform¬ 
ing  it--  if  it  is,  it  signals  a  Fattl-Recurtion  condition  which  may  either  he  caught  by  ARLO's  “expect  at  i  .-ns"  -  r 


reported  t- ■  the  user. 
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2.3.2  Classes  of  Errors 

A  newly  loaded  ARLO  defines  a  small  collection  of  special  conditions.  As  ARLO  (and  programs  using  it) 

venture  into  new  domains,  new  techniques  and  new  methodologies,  this  collection  of  conditions  should  grow 

to  become  both  more  “worldly”  and  more  tightly  connected  to  the  structure  of  ARLO. 

All  ARLO  conditions  inherit  from  the  condition  flavor  ARL0-C0UDITI0!1.  Currently,  the  following  con¬ 
ditions  are  defined  in  a  newly-loaded  ARLO: 

•  Fatal -Recursion  is  signalled  when  ARLO  notices  that  it  is  trying  to  perform  some  operation  which  is 
already  being  attempted.  The  user  is  offered  the  option  to  try  the  operation  using  non-reflexive  sub- 
primitives,  or  she  may  use  the  standard  debugger  commands  to  re-evaluate  or  return  a  value  from  the 
fatally  recursive  call. 

•  Slot-llot-Found  is  signalled  when  an  attempt  to  inherit  some  slot  through  some  relation  fails —  often 
this  error  does  not  reach  the  user,  but  is  caught  and  handled  by  ARLO  itself.  If  it  does  reach  the  user, 
she  can  proceed  by  either  providing  a  value  to  cache  locally,  trying  to  inherit  through  another  slot,  or 
looking  on  another  unit  for  the  value. 

•  Unacceptable-Value  is  signalled  when  a  value  being  stored  on  a  slot  is  of  the  wrong  type  for  that  sort  of 
slot.  If  she  wishes,  the  user  may  tell  ARLO  to  go  ahead  and  store  the  value  anyway. 

•  Unacceptable-Unit  is  signalled  when  a  slot  is  being  attached  to  a  unit  of  the  wrong  type.  As  with 
Unacceptable-Value,  the  user  may  tell  ARLO  to  go  ahead  and  store  the  value  anyway.  The  abstract 
condition  flavor  underlies  both  the  Unacceptable-Value  and  Unacceptable-Unit  condition  flavors. 

•  Boot-Conflict  is  signalled  when  a  slot  which  was  defined  before  ARLO’s  second  boostrap  is  being 
invalidated.  This  will  typically  happen  when  a  new  value  is  being  placed  there.  Going  through  with 
such  a  replacement  might  cause  a  problem  because  such  a  slot  may  —  in  its  boostrapped  configuration  — 
implicitly  depend  on  itself.  E.G.  ARLO  may  have  to  reference  the  slot  being  invalidated  in  order  to  finish 
retracting  it  or  put  a  value  in  it.  While  ARLO  is  generally  robust  about  changes  whose  dependencies 
are  explicit  (and  thus  non-circular),  all  bets  are  off  for  pre-bootstrap  definitions  which  ground  ARLO’s 
self-description. 

•  Cant -Default-Slot  is  signalled  when  the  value  of  a  slot  cannot  be  defaulted;  this  might  happen  if  the 
slot  was  never  intended  to  default,  or  if  all  known  methods  for  defaulting  the  slot  have  failed.  Often  this 
may  be  caught  by  a  prepared  handler  which  then  deposits  its  own  “default”  as  a  replacement  value. 

«  Out-Of  -Methods  is  signalled  when  a  try-and-try-again  function  runs  out  of  methods  to  try  in  computing 
.oine  value.  The  user  can  proceed  from  this  by  providing  either  a  value  to  use  as  a  result  or  another 
method  to  try.  When  this  condition  is  reported  to  the  user,  it  describes  the  methods  it  has  already  tried 


in  computing  the  value.  Often  this  error  is  caught  by  higher  level  try-and-try-again  functions  which 
move  on  to  other  higher-level  approaches  when  this  is  signalled. 

9  A  try-and-try-again  function  tries  one  method  after  another  to  compute  a  value,  moving  onto  the  next  one  if  the 
previous  fails.  ARLO  supports  two  sorts  of  try-and-try-again  functions:  one  moves  onto  the  next  method  only  if 
the  current  method  fails  in  some  “expected  way”;  the  other  is  a  blanket  version  of  the  first,  that  tries  the  next 
meth-'H  when  any  s-  -rt  f  err -r  "mirs. 
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•  Usar-Mot-Found  is  signalled  when  a  query  to  the  user  times  out.  This  should  be  connected  to  ARLO  in 
a  more  intimate  way,  using  a  user  model  to  decide  when  to  quit,  and  being  able  to  figure  other  methods 
of  contacting  the  user.  (Such  a  model  should  also  clearly  incorporate  some  theory  of  etiquette!) 

2.4  Reflexive  Operators 

ARLO’s  operation  refers  to  the  in-core  description  of  its  own  semantics  in  such  a  way  that  when  its  description 
is  modified,  its  performance  changes.  This  is  done  via  a  data-directed  mechanism  called  reflexive  operators. 
10  Reflexive  operators  are  functions  of  the  form: 

(<operator>  <unit>  <slot>  .  <remaining-arguments>) 

(where  <operator>  is  a  reflexive  operator)  and  working  by  applying  the  To-<operator>  slot  (a  slot  also  defined 
in  ARLO)  of  <slot>  to  the  arguments  <unit>,  <slot>,  and  <remaining-arguaents>  For  example,  the  form: 
(Put-Value  #>Jane  #> Age  25.) 

takes  the  result  of  (Get-Value  #>Age  #>To-Put-Value)  and  applies  it  to  the  unit  named  Jane,  the  unit  named 
Age,  and  the  number  25.  This  application  might  then  (for  instance)  verify  the  suitability  of  25  as  the  value 
for  Jane’s  age  or  perforin  various  dependency  maintenance  functions  in  addition  to  —  or  perhaps  in  place 
of  11  —  actually  depositing  the  value. 

In  the  same  manner,  the  form: 

(Retract -Value  #>Jane  #>Age) 

works  by  taking  the  result  of  (Get-Value  #>Age  #>To-Retract-Value)  and  applying  it  to  the  units  named  Jane 
and  Age.  This  will  then  —  typically  —  retract  the  value  on  the  Age  slot  of  the  unit,  named  Jane. 

2.4.1  Staunching  an  infinite  regress 

The  one  significant  exception  to  the  reflexive  operator  mechanism  is  the  Get-Value  funct  ion.  The  mechanism 
described  above  runs  into  a  snag  when  we  try  to  define  Get -Value  as  a  reflexive  operator;  we  would  like 
Get-Value  to  work  like  any  other  reflexive  operator,  evaluating: 

(Get-Value  <slot>  #>To-Get-Value) 

to  get  an  appropriate  accessor,  and  applying  this  accessor  to  <unit>  and  <slot>  to  get  a  result.  Unfortunately, 
this  approach  ends  up  infintely  recursing  12  on: 

(Get-Value  #>To-Get -Value  #>To-Get-Value) 

To  get  around  this  problem,  Get-Value  is  only  partially  reflexive:  instead  of  calling  Get-Value  to  find  a 
To-Get-Value  slot,  it  checks  <alot>  and  its  prototype s  —  a  relation  defined  as  part  of  ARLO's  initial 
configuration  —  for  a  To-Get-Value  slot.  A  slightly  cleaner  version  of  this  might  look  at  the  To-Get-Value 
data  structure  itself  for  the  function  to  use  in  its  search,  rather  than  using  a  hard-wired  definition. 

2.5  Representing  Representations:  The  Details 

‘°This  terminology  originates  with  ARLO. 

*  Iff  the  value  being  deposited  were  inapp-  rpriatc  by  some  criterion,  it  might  signal  an  error  instead  of  depositing 

the  value. 

'-ARI.O  usually  c  a  trim-  such  fatal  recursions  and  signals  an  err  r  nditi-n. 
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The  reflexive  operator  mechanism  is  an  interpreter  for  structures  specifying  the  implementation  of  frame- 
based  languages  From  a  partial  description  of  a  given  representation  language.  ARLO  generates  —  by 
inheritance  from  abstract  specifications  and  the  synthesis  of  standard  representation  functions  -  the  precise 
details  of  its  implementation.  ARLO’s  basic  definition  specifies  the  components  of  this  generation  process: 
inheritance  mechanisms,  automatic  coders,  descriptive  constraint  predicates,  etc  These  primitive  mecha¬ 
nisms  for  language  definition  are  themselves  described  in  ARLO's  “pre-configured”  representation  and  are 
interpreted  by  reflexive  operators  in  specifying  and  compiling  other  representations.  The  primitive  definition 


of  this  core  can  thus  be  extended  or  changed  - —  carefully!  —  to  alter  or  expand  the  capabilities  of  the 
language. 


ARLO’s  central  core  is  bootstrapped  by  setting  up  an  initial  description  —  to  be  interpreted  by  reflexive 
operators  —  for  a  simple  representation  language.  Facilities  like  coders  and  more  complicated  representation 
compilers  are  then  described  (and  executed)  in  this  representation  langauge. 

In  ARLO’s  central  core  language,  the  primary  inheritance  mechanism  —  the  mechanism  by  which 
properties  are  declared  abstractly  and  then  propogated  to  particulars  —  is  Prototype  inheritance.  This  sort 
of  inheritance  generates  defaults  for  values  by  searching  along  the  Prototype  relations  between  units.  The 
Prototype  hierarchy  is  an  exception-shadowing  hierarchy  of  slot  inheritance  which  keeps  dependencies  for 
its  inherited  and  cached  values.  While  representation  facilities  built  in  ARLO  define  and  use  other  sorts  of 
inheritance  mechanisms,  ARLO  itself  goes  little  beyond  this  simple  mechanism. 

When  a  user  begins  building  a  representation  in  ARLO,  she  generally  uses  the  Prototype  relation  to  refer 
to  a  collection  of  pre-defined  abstract  slot  descriptions,  from  which  the  particulars  of  ARLO  and  its  embedded 
representations  inherit.  A  newly  bootstrapped  ARLO  has  a  small  collection  of  these  prototypical  slots, 
defining  simple  classes  of  relations  whose  implementation  details  inherit  through  the  Prototype  hierarchy; 
extensions  to  ARLO  may  well  define  entirely  new  such  classes  of  slots  beyond  these. 

The  most  basic  sort  of  slot  is  the  Primitive-Slot;  Primitive-Slot  is  a  non-defaulting,  lion-restrictive 
slot,  and  lies  at  the  root  of  the  Prototype  hierarchy  of  slots.  The  Prototype  relation  is  a  primitive  slot, 
but  most  other  slots  lie  deeper  in  the  slot  inheritance  hierarchy  (the  Prototype  hierarchy)  than  this.  The 
first  level  of  slot-types  defined  beneath  Primitive-Slot  are  Generic-Slots.  Generic  slots  are  the  way  ARLO 
implements  generic,  objects ,  an  object  oriented  (as  opposed  to  slot  oriented)  method  of  dispatching  certain 
slot  and  unit  operations. 

Beneath  Generic-Slot.  ARLO  defines  Typed-Slots  whose  values  and  attachments  (the  units  they  attach 
their  values  to)  must  satisfy  certain  predicates.  Beneath  Typed-Slot  is  defined  Slot,  the  protoypical  slot 
referred  to  by  most  of  ARLO’s  definition.  Slot  is  a  generic  type-restricted  slot  which  may  compute  “assumed’’ 
values  for  its  assignments. 

The  functional  properties  of  these  slots  are  not  —  unfortunately  —  -  automatically  merged  from  com¬ 
ponents  along  the  hierarchy,  but  are  hand-coded  into  implementation  functions  at  for  each  new  type  of 
slot  The  To-Put-Value  slot  of  Typed-Slot  for  instance,  is  hand-coded  to  operate  generically,  rather  than 
automatically  accquninp  the  generic  nature  of  Generic-Slot’s  modifiers.  Of  course,  this  hand-coding  is  only 
m  ccessary  because  they  share  the  functional  role  of  slot  modification;  the  To-Put-Value  slot  of  the  defaulting 
Slot  need  not  be  specially  coded,  since  Slot  defines  no  new  modification  functionality  and  may  just  inherit 
Typed-Slot  -  To-Put-Value  without  meiging 

20 


ARLO 


Ken  Haase 


2.5.1  Generic  Objects  &  Shadow  Slots 


ARLO  implements  generic  objects  —  as  in  SmallTalk  IGR84'  or  flavor .«  jWM82)|CanS3j  —  with  a  mechanism 
called  shadow  slots.  In  languages  like  SmallTalk  or  the  Lisp  Machine  flavor  system,  the  primary  functional 
operation  is  message  passing,  where  an  object  is  sent  a  message  in  order  to  perform  an  operation  on  or 
with  it.  These  languages  are  generic  in  that  each  object  (or  more  precisely,  each  class  of  objects)  has 
local  definitions  for  handling  the  messages  it  receives  in  different  ways.  In  ARLO,  on  the  other  hand,  the 
primary  functional  operation  is  slot  access  (though  the  slot  accessed  may  contain  the  definition  of  some 
functional  operator),  and  the  character  of  the  operation  is  determined  by  the  global  description  of  the  slot 
being  accessed.  Slots  which  are  generic ,  however,  permit  a  unit  to  shadow  their  global  definition  with  a 
locally  specified  redefinition;  these  redefinitions  are  other  full-fledged  slot  descriptions  which  supersede  the 
global  defaults.  Thus,  particular  units  may  redefine  some  slot’s  definition  (where  the  definition  is  an  ARLO 
description)  for  themselves. 

Shadow  slots  are  implemented  as  a  non-invasive  extension  of  ARLO.  By  noil-invasive,  I  mean  that  the 
implementation  does  not  modify  ARLO’s  reflexive  operator  mechanism  but  simply  builds  upon  it.  This  is 
done  by  having  the  implementation  of  a  generic  slot  (as  functions  stored  on  the  slot’s  description)  explicitly 
check  for  replacement  definitions  of  themselves  on  the  the  unit  they  are  operating  on.  Most  of  ARLO’s  slots 
(and  most  of  the  slot  accessing  functions  offered  to  users)  contain  this  explicit  check,  encoded  by  the  macro 
Shado  :ing-Slot. 

A  generic  slot  looks  for  any  “shadowed”  definitions  of  itself  by  extracting  its  own  Shadov-Slot-Slot 
from  the  unit  it  is  operating  on.  For  instance,  the  Hone-Phone  slot  might  have  a  Shadow-Slot-Slot  of 
Shadoved-Home-Phone-Slot.  The  Shadov/ed-Home-Phone-Slot  of  any  particular  unit  then  contains  the  re¬ 
definition  of  Home-Phone  —  if  any  —  to  use  on  that  unit.  Then,  descriptions  of  people  with  unusual  phone 
numbers  —  overseas  or  buried  in  extensions  —  might  have  a  Shadowed-Home-Phone-Slot  whose  defini¬ 
tion  would  make  their  numbers  acceptable  or  accessible  despite  some  assumed  global  standard  defined  on 
Home-Phone 


2.5.2  Type  Restricted  Slots 


Another  abstract  slot  is  the  type  restricted  slot.  The  type  restriction  mechanism  in  ARLO  refers  to  types 
defined  in  a  non-excepting  generalization  hierarchy  of  predicates;  the  value  and  attachment  (the  unit  a  slot 
attaches  its  value  to)  of  a  type-restricted  slot  are  constrained  by  a  pair  of  these  types.  (This  hierarchy  is 
described  in  further  detail  in  Section  2.7.)  The  Data-Type  slot  of  a  type-restricted  slot  determines  what  types 
of  values  the  slot  may  accept;  its  Makes-Sense-For  slot  determines  what  types  of  objects  (typically  units) 
the  slot  may  be  attached  to.  The  type  checking  predicates  of  a  slot’s  Data-Type  and  Makes-Sense-For  slots  are 
merged  into  its  To- Verif y-Type  slot;  this  value  is  a  function  of  a  unit,  slot,  and  value  about  to  be  combined 
w  hich  signals  an  error  if  either  of  the  predicates  fails.  This  error  is  proceedable.  but  of  course  such  an  action 
may  have  dangerous  repercussions. 

Most  of  the  slots  of  ARLO’s  initial  configuration  are  type  restricted  slots,  constraining  themselves  by 
irbuente  t"  the  predicate  generalization  hierarchy:  but  the  relations  forming  this  hierarchy  (in  then  recursive 
tutu)  ate  dt->  ribed  and  defined  by  ARLO.  This  circularity  of  reference  is  initially  established  when  the  type 
he  i  ii<  1 1 s  i-  I  i  i a -t i  a pped  (let  ailing  Figure  2-1).  a  major  event  in  A R LC >  t ompilat ion  and  deployment 
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2.5.3  Defaulting  Slots 

SLOT  is  the  abstract  slot  first  referred  to  by  most  representations  built  on  top  of  ARLO.  As  well  as  having 
type  restrictions  as  described  above,  units  inheriting  from  SLOT  have  defaulting  methods  for  generating  absent 
values.  When  no  value  for  this  sort  of  slot  can  be  found  directly  on  a  unit,  a  default  is  generated  by  calling 
the  function  stored  on  the  slot  description’s  To-Def ault-Value  slot.  This  function  is  called  on  both  the  unit 
being  referenced  and  the  slot  being  defaulted  and  returns  the  value  computed  and  a  truth-value  (T  or  NIL) 
to  indicate  the  success  of  the  computation.13 

Often,  the  To-Def  ault-Value  property  of  a  particular  slot  must  also  be  generated  by  default;  the  To-Def  ault-Value 
slot  of  To-Def  ault-Value  first  tries  to  get  a  LISP  implementation  off  of  the  slot’s  High-Level-Def  inition 
and  failing  this,  ascends  the  hierarchy  of  abstract  slot  specifications  (the  Prototype  hierarchy)  looking  for 
a  To-Default-Value  slot  to  use.  A  slot’s  High-Level-Def  inition  —  if  it  has  one  —  is  an  abstract  function 
description  which  may  be  implemented  by  a  lisp  coder  as  described  in  Section  2  6  below. 

In  the  final  analysis,  the  semantics  of  most  slots  built  on  ARLO’s  core  (those  inheriting  from  CORE  SLOT) 
are  determined  by  the  two  components  of  ARLO  just  introduced:  the  coder  mechanism  which  describes 
how  “assumed”  properties  are  computed  and  the  type  mechanism  which  constrains  the  values  of  slots  by 
predicates  in  a  generalization  hierarchy  Both  of  these  modules  are  described  in  more  extensive  detail  below. 

2.6  The  ARLO  Coder 

ARLO  implements  a  facility  called  coders  for  generating  lisp  code  from  high  level  functional  descriptions. 
This  facility  is  implemented  by  a  representation  language  —  described  and  implemented  in  ARLO  —  for 
describing  LISP  functions.  I'sing  this  language,  a  user  —  or  a  sophisticated  program  —  describes  how  partial 
specifications  of  particular  sorts  of  function  are  expanded  into  fully  implemented  lisp  definitions.  Coders 
allow  common  representation  function-  like  property  inheritance,  network  searches,  function  composition, 
or  value  restriction  to  he  generated  from  their  functional  specification.  Every  coder  generated  function 
begins  with  an  ARLO  unit  which  partially  describes  the  function  to  be  generated;  the  operational  slots  of 
the  function  description  its  lambda-definit ion,  documentation,  etc  ■—  are  generated  as  defaults  from  this 
dost  i  ipt i> »n .  When  a  user  or  program  define-  a  particular  coder,  -lie  is  actually  defining  the  wav  in  which 
certain  slot.-  such  as  Lambda  Definition  or  Documentation  default  for  a  particular  sort  of  functional 
descnpt  ion . 


Each  time  a  coder  implements  a  particular  function,  it  constructs  a  unit  describing  the  function;  the 
LISP  definition,  documentation,  and  name  of  the  function  are  then  generated  by  referring  to  methods  stored 
on  the  Coded  By  slot  of  the  description  The  value  of  the  Coded-By  slot  is  also  an  ARLO  unit  -  a  coder  — 
which  has  functional  properties  like  Implementor,  Documentor,  or  To- Lame -Function  Coders  —  with  these 
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relevant  slots  —  are  defined  by  a  Def  ine-Coder  form: 

(Def ine- Coder  (  Coder-name  .  description-parameters) 
documentation-  for  -coder 

(  function-name-specification  .  arguments-for- function) 
documentation-specification 
body- specification) 

Defme-Coder  constructs  a  unit  named  coder-name  which  describes  how  to  generate  functions  of  some 
particular  type  from  specified  description-parameters.  These  functions  are  actually  generated  as  appropriate 
Lambda-Definition  slots  for  descriptions  which  are  initialized  with  some  given  description-parameters.  De¬ 
scription  parameters  are  slots  stored  on  the  functions’  descriptions,  and  it  is  by  reference  to  these  properties 
of  the  description  that  the  coder  generates  implementations,  names,  and  documentation. 

Each  description  parameter  is  either  a  symbol  —  in  which  case  an  indistinguished  function-describing 
slot  with  that  name  is  created  —  or  a  list  whose  first  element  specifies  a  slot  /parameter  name,  and  whose 
remaining  arguments  are  slot-value  pairs  to  be  deposited  on  the  slot’s  description  (perhaps  affecting  it’s 
implementation). 

Function- Same-Specification  specifies  how  to  generate  names  for  the  functions  the  coder  generates. 
If  it  is  a  symbol  (such  as  MATRIX-lIULTIPLY),  each  function  name  is  an  iterated  gensym  of  that  symbol 
(e  g.  ;iATRIX-i;ULTIPLY-7).  If  the  specification  is  a  lisp  form,  it  is  evaluated  to  produce  each  function  name, 
referencing  the  description-parameters  of  the  coded  function  as  free  variables,  and  the  function  description 
itself  by  the  variable  coder-name. 

Arguments- For- Function  is  the  argument  list  for  each  function  the  coder  generates.  ARLO  also  knows 
how  to  extract  the  argument  list  for  general  system  functions  not  synthesized  by  ARLO,  allowing  operations 
whicli  use  the  argument  list  —  such  as  functional  composition  —  to  be  applied  to  functions  defined  by  either 
the  user  or  other  resident  systems. 

Documentation- Specification  is  a  form  which,  accessing  the  description  parameters  and  function  descrip¬ 
tion  as  free  variables,  prints  documentation  for  the  function  to  the  stream  STAUDARD-OUTPUT 

Finally,  body -specification  is  a  lisp  form  returning  the  body  forms  of  the  function  generated  by  the  loder. 
As  with  the  previous  structure  generating  forms,  this  form  may  reference  the  description  parameters  and 
function  description  as  free  variables. 

The  Def ine-Coder  form  creates  a  coder  description  an  ARLO  unit  named  coder-name  which 
describes  how  to  generate  names,  documentation,  and  lambda  definitions  lor  the  functions  it  <odes  It 
also  implements  a  generator  function,  named  coder-name,  which  constructs  a  function  description  with  the 
appropriate  CODED-BY  slot  and  with  description  parameters  from  its  arguments.  The  function  defaults  the 
lambda-definition  —  and  LISP  compiled  definition  for  this  function  description,  finally  returning  the 
generated  name  of  the  function. 

2.6.1  Representing  Programs 

The  coder  mechanism  was  originally  conceived  as  an  embryonic,  poor  man's  version  of  the  jdnn  cliche  repre¬ 
sentation  used  in  the  Programmer’s  Apprentice  project  at  WIT  SR7c>  .Run1  Wat7r  B\  representing  ty  pical 
i  epi  esent  at  ion  function-  in  this  explicit  way.  the  task  'if  understanding  m  ml  elligeiii  ly  modifying  ARLO 
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definitions  is  far  more  straightforward.  Mutative  systems  such  as  AM  and  Eurisko  generally  modified  LISP 
functions  by  heuristically  munging  s-expressions  which  encoded  LISP  definitions  of  relevant  functions  The 
coder  mechanism  was  designed  to  make  explicit  and  accessible  in  an  ARLO  reptesent  at  ion  descriptions 
of  the  implementations  of  many  of  the  system’s  functions  and  operations 

2.6.2  ARLO's  Coders 

The  initial  ARLO  configuration  defines  7  coders: 

•  Slot -Compos  it  ion  takes  a  list  of  slots  and  constructs  a  function  which  is  their  composition  For  instance  a 
composition  of  the  Father  and  Mother  slots  would  be  a  function  for  extracting  ones  paternal  grandmother. 

•  Inherit-Through  generates  a  function  for  inheriting  through  a  particular  relation. 

•  Methods  constructs  a  composite  function  from  a  list  of  other  functions,  which  may  also  be  generated  by 
coders.  The  function  generated  tries  each  function  —  one  after  another  —  until  one  succeeds  (returns 
without  error).  This  function  is  called  a  try-and- try- again  function,  trying  one  method  after  another 
until  one  finally  succeeds,  being  careful  about  the  accumulated  dependencies  of  each  attempt  (it  resets 
the  dependency  tracking  mechanism  before  each  attempt.) 

•  Expecting  is  like  Methods,  but  the  function  it  constructs  only  “tries  again”  if  a  preceding  method  fails 
in  an  “expected”  way.  Of  course,  if  an  unexpected  error  occurs  inside  of  an  Expecting  function,  it  may 
well  be  caught  by  other  Expecting  or  Methods  coded  functions  above  it  in  the  calling  sequence 

•  Test  is  a  coder  which  generates  a  predicate  function  which  is  the  conjunction  of  it ^  component  functions. 

•  Inherits7  is  a  coder  for  predicates  which  determine  if  one  unit  inherits  from  some  other  through  some 
relation  (For  instance,  if  some  person  is  directly  above  some  other  in  some  hierarchy.) 

•  Type-Checker  generates  the  function  for  verifying  a  slot’s  assignment  —  its  value  and  attachment 
from  the  slot’s  Mmkes-Sense-For  and  Date-Type  properties. 

2.6.3  User  Defined  Functions 

The  function  description  language  used  by  the  coder  is  also  used  to  record  user  function  definitions.  The 
function  DEFII'E  has  the  syntax  of  LISP’s  DEFUII,  but  builds  an  ARLO  description  with  appropriate  Lambda- 
Definition  and  Documentation  slots.  The  function  AA  is  an  inline  version  of  DEFI  '.  E  which  returns  the  name 
of  the  function  it  defines. 

The  function  GET  -FU::CTI  01!-  DESCRIPT  10b  finds  or  generates  an  A  R  L<)  desc  ript  imi  of  t  lie  fund  ion  specified 
by  its  single  argument.  Of  course,  if  the  function  was  not  appropriately  defined  (by  DEFI!  E,  A\,  or  some 
automatic  coder),  some  information  (such  as  lambda  definitions)  may  not  be  available 

2.7  The  Type  System 

The  coder  mechanism  is  used  by  ARLO  in  two  roles:  the  implementations  of  “defaulting  functions,”  and 
the  specification  of  ARLO’s  hierarchy  of  types.  In  this  second  role,  coders  are  defined  which  implement 
common  representational  predicates  (such  as  checking  inheritance  over  various  relations)  and  particular  con¬ 
junctions  of  such  predicates.  These  generated  predicates  are  defined  in  a  gt  ruralizatuin  hierarchy,  descending 
from  broader  predicate-  (satisfied  by  large  numbers  of  objects  and  units)  into  progre.-siveh  nioie  partkiilai 
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predicate  categorizations.  Each  of  the  predicates  in  this  hierarchy  is  represented  by  a  “type,”  an  ARLO 
description  which  consolidates  a  predicate  function  with  associated  functions  for  describing  and  operating 
on  objects  which  satisfy  the  predicate.  ARLO’s  “type  hierarchy”  is  the  predicate  generalization  hierarchy 
imposed  between  these  type  descriptions. 

The  type  hierarchy  also  fills  two  distinct  roles  in  ARLO’s  initial  configuration.  First  of  all,  its  predicates 
serve  to  constrain  the  “sensible”  attachements  and  values  for  particular  slots;  secondly,  it  provides  informa¬ 
tion  about  how  to  print,  describe  and  parse  the  sorts  of  values  known  to  belong  to  certain  sorts  of  slots.  For 
systems  implemented  in  ARLO.  beyond  the  definition  of  ARLO  itself,  it  both  provides  constraints  on  the 
generation  of  new  slots  from  old  and  serves  as  a  hook  for  hanging  type  specific  knowledge  in  the  form  of 
inference  procedures  or  heuristics. 

The  generalization  hierarchy  between  types  is  determined  by  two  slots:  the  Generalization  slot  and 
the  Specification  slot.  The  Generalization  of  a  type  is  the  type  upon  which  a  type  is  built;  a  type’s 
Specification  determines  what  additional  criterion  objects  of  the  type  must  satisfy.  The  predicate  for  a 
given  type  is  hence  the  conjunction  of  the  type’s  specification  and  the  predicate  of  its  generalization.  This 
principle  yields  a  strict  generalization  hierarchy  —  any  instance  of  T  is  also  an  instance  of  Gtneruhzation(T) 
—  which  simply  supports  operations  like  classification  (quickly  finding  the  types  which  an  instance  satisfies 
by  traversing  downwards  the  tree  of  generalizations)  or  property  clustering  (automatically  generating  new 
types  from  old  by  specializing  around  particular  property  regularities  in  their  instances).  In  addition  to 
providing  a  formal  framework  streamlining  these  sorts  of  operations,  the  generalization  relation  is  used  to 
inherit  type  specific  properties  such  as  display  functions,  description  parsers,  or  inference  procedures. 

The  type  system  presents  its  own  bootstrap  problems;  it  is  described  in  ARLO  (as  as  a  representation 
langauge  for  hierarchically  organizing  predicates  and  their  properties),  but  is  used  (in  turn)  to  constrain  the 
values  and  attachments  of  ARLO’s  own  definition.  As  a  result,  ARLO’s  type  bootstrap  is  move  complicated 
than  its  representation  bootstrap  (which  was  described  in  Section  2.5).  When  ARLO  is  originally  defined 
as  a  representation  describing  language,  its  type  restrictions  and  constraints  are  represented  by  symbolic 
tokens  referring  to  type  names.  ARLO’s  second  bootstrap  —  its  type  bootstrap  —  takes  these  symbolic 
tokens  and  replaces  each  type  name  in  ARLO’s  self-description  with  a  pointer  to  the  actual  type-describing 
unit  it  refers  to.  The  timing  of  this  bootstrap  is  critical,  as  the  type  system  uses  both  ARLO  and  the  coder 
mechanism  in  its  definition,  and  enough  of  these  mechanisms  must  be  compiled  and  cached  before  the  type 
system  ts  completely  enabled 

The  package  of  ARLO  utilities  implemented  for  CYRANO  significantly  extends  the  type  system  into  a 
general  classification  system  This  extension  includes  a  classifier  for  placing  instances  in  the  hierarchy  of 
predicates  (similar  to  the  KL-O'.'E  classifier)  and  an  implementation  of  heuristic  and  inferential  rules  whose 
“IF”  components  refer  to  the  type  hierarchy.  This  innovation  automatically  places  rules  in  a  generaliza¬ 
tion-specialization  hierarchy  from  which  they  may  be  indexed  to  particular  objects  or  tasks.  A  new  variety 
of  automatic  predicate  coders  accompanies  this  extension,  permitting  the  specification  of  constraints  on  and 
between  various  sub-parts  of  descriptions. 

2.8  Archives  and  Layers:  Saving  Representations 
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Upon  the  edifice  described  in  the  preceding  sections,  users  and  clever  programs  build  both  new  representation 
schemes  and  particular  representations  within  those  schemes.  Much  of  this  construction  takes  place  in  the 
same  manner  as  ARLO’sown  initial  construction:  through  top  level  forms  which  side-effect  the  environment 
to  install  particular  representations  and  representations  of  representations.  But  much  of  the  structure  built 
on  top  of  ARLO  is  a  dynamic  stuff,  constructed  by  interactive  editors,  database  parsers,  or  thoughtful 
programs.  The  preservation  of  these  structures  —  defined  in  no  particular  file,  but  only  by  the  accumulation 
of  definitions  and  mutations  over  time  —  is  critical  if  any  of  our  programs  is  to  have  a  life  beyond  a  single 
session  or  a  handful  of  examples. 

Archives  and  layers  are  ARLO’s  tools  for  saving  out  collections  of  in-core  units  and  their  relations;  units 
and  relations  are  dumped  as  data  files  from  which  they  may  later  be  restored.  An  archive  stores  a  collection  of 
units  and  their  connections,  a  layer  stores  the  changes  in  such  collections  of  units  and  connections.  Archives 
are  used  to  store  bodies  of  knowledge  and  the  representation  schemes  (in  ARLO,  another  sort  of  body 
of  knowledge)  in  which  they  are  expressed;  layers  are  used  to  store  personal  modifications  or  incremental 
changes  to  these  archives. 

The  implementation  of  archives  and  layers  posed  many  difficult  ies,  most  of  the  arising  front  the  circularity 
and  complexity  of  ARLO's  inter-relations  and  dependencies.  It  is  worth  noting  that  the  Lisp  Machine  system, 
not  designed  to  support  the  structured  preservation  of  partial  environments,  had  to  be  significantly  extended 
to  permit  dumping  of  ARLO  structures.  This  section,  however,  will  concern  itself  only  with  the  dumping 
abstractions  used  by  ARLO,  and  not  the  implementation  particular  details  of  their  realization. 

Like  nearly  every  other  process  in  ARLO,  the  dumping  of  ARLO  units  and  relations  is  dat.a-directed. 
The  archive  to  which  a  unit  belongs  is  a  slot  of  the  unit;  every  ARLO  unit  is  given  (or  assumes  by  default)  a 
dy-File-Of-Definition  slot.  For  units  defined  by  top-level  LISP  forms,  this  is  the  file  in  which  the  LISP  forms 
appeared;  for  other  units,  this  slot  is  the  archive  the  unit  is  defined  in.  A  unit’s  archive  is  either  an  explicitly 
deposited  pathname  or  (by  default)  a  logical  pathname  fo  the  form  ’  ‘ARLO  XBases,  kb  Bl.’i  >“,  where  kb 
is  the  knowledge  base  the  unit  was  originally  defined  in.  The  #>My-File-Df -Definition  slot  is  defined  (as  an 
ARLO  slot)  to  maintain  backpointers  from  archive  pathnames  to  the  units  defined  in  them.  Thus,  when  the 
user  asks  to  dump  and  archive  (specified  by  its  pathname),  the  set  of  units  to  be  dumped  are  available  as  a 
property  of  the  pathname. 

An  archive  is  dumped  through  forms  which  bind  —  at  load  time  —  particular  unit  names  to  unit  objects; 
the  reference  to  each  unit  object  is  then  realized  in  forms  which  access  or  regenerate  the  unit  Any  given  unit 
reference  is  either  local  or  eiiernul:  a  local  unit  reference  refers  to  a  unit  in  the  current  archive;  an  external 
unit  refers  to  a  unit  in  some  other  archive.  External  unit  references  dump  as  a  pair  of  unit  name  and  unit 
archive;  if  -  at  load  time  —  the  unit  name  is  unbound,  its  archive  is  loaded,  and  the  unit  is  then  directly- 
referenced 

Local  unit  references  dump  as  either  per-hle  dumped-object  indices  (supported  natively  by  the  ZetaLisp 
binary  dumper)  or  as  forms  which  regenerate  the  unit  In  the  first  case,  a  regenerating  form  has  already 
appeared  in  the  file  and  the  restored  object  is  directly  referenced,  in  the  second  case,  the  regenerating  form 
must  be  produced,  and  this  production  is  done  bv  calling  the  #>:  !y  -  To- Dump- Self  slot  of  the  unit  on  the 
unit.  Tin-  value  leturned  by  this  function  is  a  form  which  regenerates  the  unit  and  any  attached  portions 
'  if  it  -  envii  oniiicui  I'm  in-i. in- e  when  a  f  u  net  ion  de.-t  ri  I  >in  g  n  n  it  is  legenei  at  ed,  n  s  defmit  ion  i-  recompiled 
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into  the  load-time  environment:  if  a  unit  describing  an  active  process  is  loaded,  that  process  might  be 
instantiated  and  started  when  the  unit  is  restored.  The  #>I!y-To-Dutnp-Self  slot  of  a  unit  need  only  take 
care  of  reestablishing  particular  parts  of  the  LISP  environment  dependent  on.  or  depended  on  by,  the. unit 
dumped.  A  collection  of  canonical  dumping  functions  (such  as  DEFAULT-U:!IT-DU:.'PER)  provide  regeneration 
forms  which  handle  reestablishing  the  ARLO  environment  connected  to  a  particular  unit  These  forms  must 
not  only  reestablish  a  frame  with  its  connected  slots,  but  must  reestablish  the  units  and  slots  those  slots 
refer  to:  when  this  reestablishment  must  reach  between  archives,  it  becomes  insoluble  in  general  and  difficult 
in  particular. 

The  problem  can  be  characterized  in  the  following  way.  Every  archive  has  an  edge  where  it  connects  to 
other  archives;  a  given  archive  has  certain  assumptions  about  what  lies  over  its  edge,  but  it  only  has  limited 
information  about  the  content  of  these  bordering  archives.  When  an  archive  is  reloaded,  it  is  not  reloaded 
in  a  vacuum,  but  must  be  established  with  its  original  edge  connections  intact.  When  inconsistent  changes 
have  been  made  to  multiple  archives  (an  archive  X  refers  to  a  unit  in  an  archive  Y  which  was  never  dumped) 
the  problem  is  insoluble;  but  if  a  degree  of  consistency  is  maintained,  then  the  problem  of  establishing  an 
archive  amongst  its  neighbors  requires  dumping  the  archive  to  gust  beyond  tts  edge. 

Most  of  the  responsibility  for  reestablishing  the  cross-archive  network  is  carried  by  ARLO’s  dependency 
network.  Since  this  network  specifies  most  of  the  explicit  or  implicit  connections  in  the  ARLO  slot  network, 
rees. ublishment  of  the  dependency  network  reestablishes  parts  of  the  ARLO  unit-slot  network  as  well.  By 
using  references  to  dependencies  over  a  given  edge,  many  of  the  problems  of  dumping  partial  environments 
ate  finessed  or  solved:  “assumptions”  of  the  network  just  outside  a  particular  archive  —  just  over  its  edge 
are  found  or  recreated  when  tile  archive  is  loaded.  When  this  search  or  recreation  fails  (when  an  external 
dependency  is  assumed  that  does  not  exist)  the  loader  “fakes”  the  dependency  and  warns  the  user  of  the 
temporarily  patched  inconsistency. 

2.8.1  Layers 

Layers  are  the  way  ARLO  records  incremental  changes  to  its  descriptions.  Their  mechanism  is  quite  simple: 
at  some  point  (typically  after  an  archive  or  set  of  archives  is  loaded)  the  state  of  a  collection  of  archives 
is  frozen  into  a  “layer”.  Then,  at  some  later  point  after  a  series  of  introductions  and  modifications  to  the 
archives,  the  differences  between  the  frozen  layer  and  the  current  state  of  the  archives  is  computed,  ami 
appropriate  modifying  forms  ate  dumped  in  much  the  same  manner  as  an  archive  In  this  process  the  data 
direction  and  cross-archive  connection  proceeds  as  above. 


Ken  Haase 


•ttl 

$ 

vi 


!y.*.r 


Chapter  3 

An  Example:  Representation 


This  section  describe  a  toy  ARLO  database  of  researchers  and  their  interrlations.  It  is  part  of  the  default 
system,  residing  in  the  Inquir  knowledge  base,  useful  for  testing  and  demonstration.  The  first  section  of  this 
example  describes  and  explains  what  the  code  in  the  file  looks  like;  the  second  is  a  script  of  an  interactive 
examination  on  the  LISP  Machine  —  of  the  domain  and  its  representation  langauge. 

3.1  Building  Basics 

The  first  step  in  building  a  representation  system  in  ARLO  is  to  define  t lie  basic  essential  units  and  relations 
on  which  the  individuals  and  relations  of  your  representation  will  build.  If  you  are  building  on  top  of  raw 
ARLO.  the  inheritance  mechanism  you  ate  likely  to  use  is  #>Prototype  inheritance;  if  you  are  using  a  system 
built  on  top  of  ARLO  (for  instance,  an  FRL  or  KLONE  clone)  you  may  be  using  an  entirely  different 
mechanism  Of  course,  if  you  wish,  you  can  easily  implement  your  own  inheritance  scheme  in  ARLO  and 
use  that 

Tin-  following  expressions  describe  the  prototypical  person,  construct  a  unit  describing  the  “person 
type”,  and  build  a  prototypical  slot  from  which  slots  referring  to  people  will  eventually  inherit. 

(DefUnit  Person 

(Cescnption  ''This  is  the  prototypical  person  ’’)) 


*  *  ■  /*  t’  e  •  •  '  ■ 
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(DefUnit  Person-Type  ] 

(Description  < 

''This  is  a  type  Batisifed  by  any  unit  inheriting  from  Person  "•) 

(Prototype  #>*ny-Iyp«)  i 

(Generalization  #>Umt-Typ») 

(Specification  (Inherits’  #>Ptr«on  #>Prototype))  ! 

(#>Function-To-Find-Int«r»ctively  'get-person-from-menus) 

(#>Function-To-Rsa<!  ' read -per Bon)  ) 

(Put-Value  #>P«r«on  #>Wy-Sp«cific-Typ«  #>Per»on-Iype) 


(DefUnit  Person-Slot 
(Description 

‘‘This  is  the  prototypical  slot  which  attaches  to  people  **) 

(Prototype  #>Slot) 

(Hakes -Sense- For  #>P«r«on-Type)  ) 

The  definition  of  the  #>Person  unit  constructs  a  ‘'placeholder”  to  which  individual  people  descriptions 
will  refer.  Later,  we  may  burden  this  unit  with  a  variety  of  information  which  those  individual  people 
descriptions  will  inherit  of  refer  to.  For  instance,  the  #>Person  unit  may  be  used  to  shadow  some  slot 
definitions  in  order  to  accomodate  the  restrictions  and  potentials  of  people. 

#>Person-Type 

is  defined  as  a  specialization  of  #>Unit-Type  which  requires  inheritance  --  via  the  #>Prototype  relation 
—  from  the  unit  #>Person.  The  generalization  hierarchy  used  for  types  is  a  non-excepting  hierarchy  of  pred¬ 
icate  specifications.  ARLO’s  utilities  implement  a  KLONE-style  classifier  for  this  generalization  hierarchy, 
determining  which  types  in  the  hierarchy  are  instantiated  by  a  given  LISP  object  or  ARLO  description. 

The  #>::y-Specif  ic-Type  slot  of  a  unit  is  an  ARLO  type  description  subsuming  all  ARLO  units  inheriting 
(via  the  #>Prototype  relation)  from  the  unit.  #>Person-Type  is  deposited  there  as  a  forethought;  if  we 
had  asked  for  the  #>'Iy-Specif lc-Type  slot  of  #>Person  without  storing  #>Person-Type  there  beforehand,  an 
appropriate  type  description  would  have  been  generated  on  the  fly.  One  thing  we  will  exploit  #>Person-Type 
for  is  defining  the  way  references  to  people  are  parsed,  printed,  and  described. 

Finally.  #>Person-Slot.  is  a  version  of  #>Slot  which  embodies  a  particular  constraint  on  the  units  it  may 
be  attached  to. 

3.2  Defining  Slots 


The  following  expressions  define  slots  for  the  various  appellations  for  individual  people;  these  slots  present 
a  variety  of  different  value  defaulting  mechanisms. 


29 


ARLO 


Ken  Haase 


(DefUmt  Full-Name 

(Description  "This  is  the  full.  formal  name  of  s  person  '•) 

(Prototype  OPeraos-Slot)  ;  Attach  to  people 

(Data-Type  #>StriBg-Typ«)  ;  Accept  strings 

(To-Default-Value  ’ask-ueer-for-slot) 

(To-Prompt-For-Value 

(AA  aek-f  or-full-name  (person  slot  stream) 

(format  stream  "V/hat  is  the  full  name  of  the  person  described  by  a’" 
person)))) 

(DefUnit  Personal-Name 

(Description  "This  is  the  informal  name  of  a  person  ’•) 

(Prototype  •>PersoB-Slet)  ;  Attach  to  people 

(Data-Type  *>Stris|-Type)  ;  Accept  strings 

(To-Default  Value 

;;  The  A  A  macro  —  briefly  mentioned  on  page  24  —  internally  defines 
;;  an  exte:nal  function  constructing  an  ARLO  description  of  the  function  at  the  same  time. 
(AA  To-Generate-Personal-Hame  (unit  slot)  ;  Extract  her  first  name 
(if  (Ignoring-Errors  (get-value  unit  t>Fall-!la»e)) 

(get-f irst-v/ord  (get-value  unit  #>Fiill-!!a*») ) 

"Friend'  ’)))) 


(DefUnit  Last-Name 

(Description  "This  is  the  last  name  of  a  person .  *') 

(Prototype  «>P*rsoa-Slot)  ;  Attach  to  people 

(Data-Type  S>Striag-Typa)  ;  Accept  strings 

(To-Default-Value 

(AA  (unit  slot)  ;  Extract  her  last  name 

(if  (Ignoring-Errors  (get-value  unit  *>Foll-I!sa») ) 

(get-last-word  (get-value  unit  *>Full-!lsm») ) 

' ' Random ' ' ) ) ) ) 

The  above  are  examples  o.  slots  which  compute  their  defaults  in  different  ways.  The  #>Full-!!ame  slot, 
for  instance,  asks  the  user  for  a  person’s  full  name  if  it  isn’t  already  specified.  The  Personal-llame  slot,  on 
the  other  hand,  extracts  the  person’s  first  name  from  her  full  name  if  possible  and  otherwise  defaults  to  a 
friendly  solution.  The  Ignoring-Errors  form  used  in  the  definition  catches  difficulties  with  inaccessible  slots 
or  formats,  returning  nil  if  any  errors  were  encountered  in  the  execution  of  its  body.  The  #>Last-!!ame  slot  is 
almost  a  copy  of  #>Personal-l!ame.  extracting  a  last  name  from  the  #>Full-!!ame  slot  if  possible  and  otherwise 
defaulting  to  a  random  solution  In  both  of  these  slots  we  see  an  explicitly  defined  lambda-definition  specified 
instead  of  an  automatically  coded  high-level  description. 

The  #>itakes-Sense-For  slot  for  all  of  these  units  defaults  from  #>Person-Slot,  and  each  accepts  only 
LISP  strings  fur  values. 
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3.3  Inheritance  Mechanisms 

The  following  slots  illustrate  how  ARLO  supports  explicitly  defined  inheritance  mechanisms  of  various  sorts. 
(DefUnit  Supervisor 

(Description  '"This  is  the  supervisor  of  e  person  ’ ") 

(Prototype  #>Person-Slot)  ;  Attach  to  people 

(Date-Type  #>P«r«on-Typ»)  ;  Chauvinist,  but.... 

(To - Default -Value  *  ask-user -f  or - si ot ) 

(To -Prompt -For- Value 

(AA  ask-for-supervisor  (person  ignore  stream) 

(format  stream  "Y/ho  is  a  hacking  for?" 

(get-value  person  t>P«rsonal-!tams))))) 

(DefUnit  Hacking 

(Description  ''This  is  what  a  person  is  hacking  on.  ’  •) 

(Prototype  *>Per»on-Slot)  ;  Attack  to  people 

(Data-Type  #>Stnng-Type) 

(To-Prompt -For- Value 

(AA  ask-f or-hacking-alot  (person  ignore  stream) 

(format  stream  “What  is  a  hacking?" 

(get-value  person  *>Per«on»l-!!ame)))) 

(High-Level-Def inition 

;;  Default  from  ones’  supervisor,  and  otherwise  ask... 

;;  (The  character  macro  *t  returns  a  DESCRIPTION  of  the 
;;  function  whose  name  follows  it.) 

(METHODS  (list  (Inherit-Through  #>Supervi»or)  #|ask-UBer-for-slot) ) ) ) 

(DefUnit  Working-in-Field 

(Description  "This  is  the  field  a  person  is  working  in  ■  *) 

(Prototype  #>Per*on-Slot )  ;  Attach  to  people 

(Data-Type  t>String-Typ«) 

(High-Level-Definition  ;  Another  way  to  say  it 

(Slot-Composition  (list  #>Hacking  #>Sup»rvi»or )  )  )  ) 

(DefUnit  '.'/edging 

(Description  "A  monkey  wrench  in  the  works  ’’) 

(Prototype  *>P«r»on-Slot) 

(Data-Type  #>Stnng-Type) 

(To-Default-Value  (AA  '/.'edge  (un  si)  (get-value  un  si)))) 

The  first  of  the  slots  defined  above  is  the  #>Supervisor  slot,  which  is  used  to  default  the  values  of 
a  variety  of  other  slots.  The  type  restriction  of  #>Supervisor  demands  that  its  value  be  another  person- 
describing  unit,  since  other  slots  will  be  looking  at.  its  value  —  with  unit  accessing  functions  —  to  derive 
their  own  values. 
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The  second  and  third  slots  defined  above  perform  inheritance  (or  defaulting)  in  different  ways.  The 
*>Hacking  slot  attempts  to  inherit  its  value  by  searching  through  the  #>Superviaor  relation,  but  if  it  fails  — 
for  any  reason  —  it  asks  the  user  for  the  value.  The  #>Methods  coder  used  to  define  this  mechanism  takes 
its  clauses  and  constructs  a  try-and-try-again  function.  (Try-and-Try-again  functions  are  briefly  described 
on  page  18.) 


The  #>V.'orking- In-Field  relation  refers  to  one’s  supervisor  for  its  value  also,  but  if  this  fails,  the  entire 
attempted  computation  fails.  In  addition,  the  #>Slot-Composition  coder  is  not  characterised  as  a  search, 
so  the  function  it  generates  will  be  implemented  somewhat  differently.  (It  will  not,  for  instance,  signal  a 
#>Slot-Hot-Found  condition  if  it  fails.) 

Finally,  the  #>kfedging  slot  is  merely  there  for  purposes  of  demonstrating  how  fatal-recursion  detection 
works.  Since  the  wedging  slot  defaults  by  getting  its  value,  trying  to  compute  a  default  for  it  will  recurse 
indefinitely. 

3.4  Shadowing  Slot  Definitions 


To  demonstrate  the  ARLO  mechani«m  for  shadowing  slots,  we  construct  two  special  units.  The  first, 
#>Shadov;ed- Hacking,  describes  how  to  find  and  store  a  shadowed  definition  for  the  OHACKING  slot;  this  de¬ 
scriptions  is  another  slot,  defined  to  get  its  value  by  searching  (with  the  LISP  function  Find-Value  through 
the  #>Prototype  slots  of  a  unit.  To  redefine  the  definition  of  #>Hackingfor  a  group  of  units,  we  merely  arrange 
that  they  have  as  a  prototype  some  unit  with  the  appropriate  #>Shadowed-Hacking  slot.  In  this  particular 
example,  we  define  a  unit  #>;.'inner  with  a  shadowed  definition  of  »>Hacking  which  asks  the  user  for  the  slot’s 
value,  without  first  trying  to  inherit  a  value  through  the  #>Superviaor  relation. 


(Def Uni t  Shadov  ed- Haeking-Def init i on 

(Description  "  A  replacement  definition  for  HACKIIIG  ’’) 
(Prototype  #>Shado- -Slot ) 

;;  Search  through  prototyp».«  for  a  value. 

(To -Default -Value 

(AA  Find-Hacking-Slot  (unit  m-slot) 

'■ Looks  for  a  replacement  hacking  definition  ’* 

(or  (find-value  unit  in-slot)  tracking) ) ) ) 

(Put-Value  *>Hacking  #>Shado.-Slot-Slot  *>Shadov.«d-Hacking-Def  ini  t  ion  ) 
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(DefUnit  V/inner 

(Description  ‘‘Somone  who  doesn't  always  follow  their  supervisor .’ ’) 

(Shadowed-Hacking-Def  lmtion 

;;  When  we  construct  ;i  unit  with  a  f>My-Haae  slot,  the  true  name 

;;  of  the  constructed  unit  will  be  an  enumerated  gensym  of  the  My-Name 

;;  slot  (e.g.  #>Hackmg-0,  #>Hacking-l,  etc). 

(make-unit  (My-Ilame  ’OHacking) 

(Prototype  #>Hacking) 

(Makes -Sense-For  (get-value  *>lJi»n«r  »>My-Spacif ic-Typa) ) 

(To-Def ault -Value  ‘ask-user-f or-slot) ) )) 

As  a  result  of  the  above  machinations,  any  person  descriptions  which  have  a  prototype  of  #>V.'inner 
instead  of  #>Person  will  use  this  alternate  definition  of  #>HACKII1G  in  place  of  the  one  originally  defined  at  the 
top  level. 

3.5  Building  the  data  base 

The  process  of  creating  “individuals”  in  this  example  builds  on  the  slots  and  prototypes  constructed  above. 
Currently,  there  are  two  standard  ways  to  build  individuals  in  ARLO.  One  may  either  call  DefUnit  explicitly 
from  top  level  (the  manner  in  which  the  slots  above  were  created),  or  write  support  functions  calling  Make-Unit 
internally  to  construct  units  with  particular  properties.  For  purposes  of  clarity  and  brevity,  this  example 
uses  only  the  first  of  these  techniques,  explicitly  defining  each  individual  person  description  at  top  level. 
The  following  DefUnit  forms  build  a  small  database  of  people-describing  units  for  an  imaginary  AI  lab. 
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(DefUnit  Calvin 

(Description  "This  is  a  well  known  robotics  hacker  ") 
(Prototype  t>Parton) 

(Full-Kame  " 'Susan  Calvin’’) 

(Hacking  ‘Robots’’)) 


(DefUnit  Rodgers 

(Prototype  #>Per«on) 

(Full-Fame  "  Robert  Rodgers”) 
(Supervisor  #>Calvin) 

(Hacking  ‘‘Emotional  Analouge  Robots’’)) 


(DefUnit  Charo 

(Prototype  *>P»rson) 

(Full-Fame  ‘‘  Elizabeth  Charo  ’  ’) 
(Personal -:;ame  ‘Beth’’) 

(Supervisor  #>Calvin) 

(Hacking  ‘‘Cognitive  Fundamentals’’)) 
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(DefUnit  Lee 

(Prototype  OPerion) 

(Full-nane  "Pat  Lee’’) 
(Supervisor  »>Calvin) 

(Hacking  "  Engineering  Design ‘ ‘ ) ) 


(DefUnit  Kyle 

(Prototype  #>Psr«on) 

(Full-IIaae  "Kyle  O’Shea")) 

(DefUnit  Arthur 

(Prototype  *>Peraon) 

(Full-!!a*e  "Arthur  Pendragon") 
(Hacking  "Fantasy  Gaaes")) 


(DefUnit  Alice 

(Prototype  *>P«r«on) 
(Full-!lame  "Alice  Adans")) 


(DefUnit  Brian 

(Prototype  t>i'inn«r) 

(Full-lla«e  "Brian  Walking-Song") 
(Supervisor  *>Ch«ro)) 


i 
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3.6  At  the  Console 

3.6.1  Defaulting  of  Slots 

(kb-goto  ’  inquir)  j Change  the  default  knowledge  (hue  j 
#<Psckage  CORE  I1IQUIR  66166707) 

(eicaaine-unit  #>Kyle)  [ Left  loot  at  Kyle’s  description.  ] 

Description  of  the  ARLO  unit  {»>KTLE} 

Description  Tho  description  of  KTLE  wee  not  provided 

Prototype  {*>PERS0H} 

Prototype  Of 

Sly  Creator  Ken  Haaae 

Sty  File  Of  Definition  ARLO  SOURCES ;  INQUIR  •  > 

Sty  Tiae  Of  Creation:  Saturday  the  twenty-eighth  of  July,  1084 ,  12  02  01  am 

Full  Dane  Kyle  O'Shea 

Sly  .’Jaae  *>KTLE 

Sty  To  Deecribe  Self  i'LOOK-AT-UMIT 

My  To  Print  Self  A ’DEF AULT- UNIT -PRIM  TER 

The  slots  of  Kyle’s  description  are  tabulated  above:  slot  names  on  the  right, 
values  on  the  left.  .Vote  that  the  values  are  printed  out  based  on  the  semantics 
of  the  slot.  #>MY-TIME-OF-CREATIOII,  while  stored  as  an  integral  number  of  seconds 
past  New  Year’s  Day  1900,  prints  out  in  a  standard  English  format.  Each  unit 
is  also  annotated  with  the  file  of  creation  and  (if  provided)  a  string  describing 
the  unit  in  English.  In  Kyle’s  case,  there  is  no  description  provided  so  a  default 
(describing  the  lack  of  an  ascribed  description)  is  provided.  But  the  description 
above  has  no  real  information  about  Kyle:  what  he  does,  who  he  works  for,  etc. 
So  we  begin  our  interaction  by  querying  about  these  things... 

Editing  {i>KYLE}  »G  Describe  Slot  Value 

’.thick  slot  of  {i>KYLE}  would  you  like  to  eeeTHacking 

Here  we  ask  for  the  Hacking  slot  of  the  unit.  Since  there  is  not  one  there 
already  (as  wt  can  tell  from  the  description  just  provided)  its  value  must  be  de¬ 
faulted  using  the  function  on  the  To-Compute  slot  of  Hacking.  This  function  - 
as  described  by  its  high  level  definition  provided  above  -  first  looks  through  the 
Supervisors  of  the  person  and  then  -  if  that  fails  -  asks  the  user  at  the  console 
for  a  value.  But  in  order  to  search  through  the  supervisors  of  Kyle  it  must  first 
know  who  his  immediate  supervisor  is.  Since  the  Supervisor  slot  defaults  by 
asking  the  user  at  the  console,  toe  are  asked... 

'..ho  le  Kyle  hocking  for’Pat 
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Pat  is  the  first  name  of  “ Pat  Lee  ”,  the  person  we  are  referrtng,  but  since  the 
value  of  the  Supervisor  slot  is  of  Person-Type,  ARLO  knows  to  read  its  value 
with  a  function  which  looks  for  people  under  their  personal  names  (as  well  as  last 
names  and  their  names  qua  description].  It  finds  the  unit  named  Lee,  based  on 
our  information,  and  caches  1 1  as  Kyle ’s  supervisor.  Having  this  information,  it 
looks  on  Lee's  description  for  a  Hacking  slot,  and  discovers.... 


The  Hacking  »lot  of  {»>KYLE}  ia:  Engineering  Design 
Thie  is  justified  by 

The  Hacking  slot  of  {#>LEE}  is  Engineering  Design 

The  To  Get  Value  slot  of  {*>HiCXIHG}  is  # 1 TTPED-DET1ULTIIIG-GET 

The  Supervisor  slot  of  {fXYLE}  is:  {i>L£E} 

The  To  Default  Value  slot  of  {«>HiCXl»C}  is 

#>  INHERIT -THROUGH- SUPERVISOR-DR -ARLO  :  ASX - USER  - FOR- SLOT -QR-ELSE 

The  To  Get  Value  slot  of  {#>TO-DEFAULT -VALUE}  is  « ' TTPED-DEFAULTINC-GET 

As  promised,  ARLO  keeps  track  of  the  dependencies  -  the  “ assumptions ” 
of  its  derivations.  In  this  case,  Kyle's  hacking  slot  depends  on  his  supervisor  being 
Lee,  Lee’s  hacking  of  “Engineering  Design,”  the  mechanism  by  which  the  hacking 
slot  defaults,  and  the  implementation  of  that  mechanism  for  defaulting.  These 
four  dependencies  are  summarized  by  ARLO  below.  Mote  that  if  any  of  them  were 
to  change  the  “assumed”  value  of  Kyle’s  hacking  slot  would  be  invalid.  Thus,  in 
the  event  that  any  of  these  values  is  retracted  or  otherwise  invalidated,  ARLO 
can  use  its  dependency  information  to  make  sure  that  the  value  just  computed  is 
retracted  and  invalidated  as  well. 


ARLO 
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3.6.2  Dependencies  and  Decaching 


1  The  dependencte 

s  ARLO  recorded  for  the  Hacking  slot  above  allow  it  to  keep  1 

the  slot’s  value  up  to  date.  This  is  neccessary  because  its  value  is  cached  on  the 

unit,  as  we  can  see  from  its  description  below: 

Editing  {#>KYLE}  >>Describe  | Describes  the  unit  ] 

Description  of  ths  ARLO 

unit  {#>KYLE} : 

Description 

The  description  of  KYLE  wee  not  provided 

Prototypo 

{»>PERS0II } 

Prototype  Of : 

None 

My  Creetor 

Ken  Haase 

My  File  Of  Definition 

ARLO  SOURCES,  1NQU1R  LISP 

My  Tiae  Of  Creation: 

Saturday  the  tsenty-eighth  of  July,  1B84,  12:02:01  am 

Fall  llase: 

Kyle  O'Shea 

Hacking: 

Engineering  Design  (7he  hacking  slot,  cached  j 

Latt  Hut 

O'Shea 

My  Name: 

f >KYLE 

My  To  Deocribe  Self 

#  *  LOOK-AT-UNIT 

My  To  Print  Self 

i'DEFAULI-UHIT-PRIllTER 

Personal  Name 

Kyle 

Supervisor : 

{#>LEE} 

[Kyle's  supervisor,  cached  also  We  won’t  be  asked  for  it  again  J 

Editing  {i>KTLE}  »Edit 

Shich  slot  of  {#>KYLE}  >. 

ould  you  like  to  edit’Siipervisor 

Now  let’s  go  look  at  Kyle’s  supervisor  and  change  his  hacking  slot.  The 

change  should  propogate  hack  to  Kyle.1* 

ARLO 
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•‘IS! 


m 


m 

i 


Description  of  the  ARLO  unit  {OLEE} 


Description  The  description  of 

Prototype  {OPERSO!!} 

Prototype  Of 

My  Creator  Ken  Haase 

My  File  Of  Definition  ARLO  SOURCES;  ItIQU 

My  Tibs  Of  Creation  Saturday  the  twenty 

Editing  {OLEE}  >>Deecribe  'Dcscnbtt  the  uru( 
Description  of  the  ARLO  unit  {#>LEE} : 


The  description  of  LEE  was  not  provided. 
{OPERSOl! } 


Ken  Haase 

ARLO  SOURCES;  ItIQUIR  •  > 

Saturday  the  twenty-eighth  of  July,  1984;  12  02  01  am 


Description 
Prototype 
Prototype  Of 
My  Creator 

My  File  Of  Definition: 
My  Tiae  Of  Creation 
Full  Haas 
Hacking 

My  Lame 

My  To  Describe  Self: 

My  To  Print  Self 

Personal  Dane 

Supervisor 


The  description  of  LEE  was  not  provided. 

{OPERSOl! } 

Ken  Haase 

ARLO  SOURCES;  ItIQUIR  •  > 

Saturday  the  twenty-eighth  of  July,  1984,  12:02:01  am 

Pat  Lee 

Engineering  Design 

The  value  which  Kyle's  Hacking  slot  defaulted  from  j 
OLEE 

d  ’  L00K-AT-U1IIT 

d '  DEF  AULT  -  Ul!  I T  -  PR  I !!  TER 

Pat 

{8>CALVin} 


Now  uie  store  a  value  in  Lee’s  #>HACKI1IG  slot.  When  reading  a  hacking  slot, 
whose  value  must  be  a  string,  ARLO  knows  to  use  the  LISP  readline  function. 
One  might  imagine  that  -  if  ARLO  were  connected  to  a  natural  language  interface 
-  the  same  sort  of  knowledge  might  be  used  to  generate  discourse  goals. 


Editing  {OLEE}  >>Sat  Slot  Value 

t'hich  slot  of  {OLEE}  would  you  like  to  aef’Hacking 

Shat  would  you  like  in  the  Hacking  slot  of  {d>LEE}?The  Grateful  Dead[A  string  it  read  ] 

Now  we  have  given  Lee  a  neu,’  hacking  slot,  and  the  value  should  have  re¬ 
placed  the  old  one.  We  ask  for  Lee ’s  description: 
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Editing  {f>LEE}  »Di«cnb»  Describes  the  urui 
Description  of  the  ARLO  unit  {#>LE£} 

Description  The  description  of  LEE  v/as  not  providtd 

Prototype  {i>PERS0N} 

Prototype  Of 

My  Creator  Ken  Heeee 

My  File  Of  Definition  ARLO  SOURCES,  IIJQUIR  •  > 

My  Time  Of  Creation  Saturday  the  twenty -eighth  of  July,  198-1  12  i»2  "1  am 

Full  Name  Pat  Lee 

Hacking  The  Crateful  Dead  The  new  value  ) 

My  Name  i>LEE 

My  To  Describe  Self  • ' LOOK-AT- UNIT 

My  To  Print  Self  f 'DEFAULT* UN IT -PRINTER 

Personal  Name  Pat 

Supervisor  {i>CALVIN} 


Editing  {#>LEE}  >>Quit 
Finished  editing  {i>LEE} 

Editing  {#>KYLE}  >>Deecribe  [Describes  the  urul 
Description  of  the  ARLO  unit  {#>KYLE} 

Description  The  description  of  KYLE  res  not  provided 

Prototype  {i>PERS0N} 

Prototype  Of 

My  Creator  Ken  Haase 

My  File  Of  Definition  ARLO  SOURCES,  1NQUIR  •  > 

My  Time  Of  Creation  Saturday  the  tv/enty-eigh th  of  July,  1984,  12  02  Ol  nm 
Full  Name  Kyle  O'Shea 

j  The  hacking  slot  --  here  before  —  has  disappeared  i 
Last  Name  O'Shea 

My  Name  #>KYLE 

My  To  Describe  Self  f ’ LOOK-AT-UKIT 

My  To  Print  Self  • 'DEFAULT -UN IT -PRINTER 

Personal  Name  Kyle 

Supervisor  {#>LEE} 

Now  we  ask  for  the  Hacking  slot  again,  and  it  will  be  defaulted  as  befort , 
except  that  this  time  Kyle’s  Supervisor  slot  is  already  known  and  doesn't  have 
to  be  asked  for. 
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Editing  {»>KTLE}  >>G  --  Deacribe  Slot  Vain* 

Khich  alot  of  {»>KTLE}  could  you  like  to  aao^Hacking 
The  Hacking  alot  of  {*>KYLE}  ia  Tha  Grataful  Oaad 
Thia  ia  juatified  by: 

Tha  Hacking  alot  of  {*>LEE}  ia  Tha  Grataful  Daad 

Tha  To  Gat  Valua  alot  of  {»>HACKINC}  ia:  * ’ TYPED-DEFAULTING-GET 

Tha  Suparviaor  alot  of  {«>KYL£}  ia  {»>LEE} 

Tha  To  Gat  Valua  alot  of  {i>SUPERVISOR }  la  ( ' TYPED-DEF AULTIKG-GET 
Tha  To  Dafault  Valua  alot  of  {*>HACKINC}  la: 

#> INHERIT -THROUGH- SUPERVISDR-OR- ARLO  ASK- USER -FOR- SLOT- OR-ELSE 

Tha  To  Gat  Valua  alot  of  {»>TO-DEFAULT -VALUE}  ia:  * 1 TYPED-DEFAULTING-GET 

Editing  {*>KTLE}  >>Daacnba  [Describe*  the  unit.  ] 

Daacription  of  tha  ARLO  unit  {»>KYL£} 


ARLO  SOURCES:  INflUIR  *  > 

Saturday  tha  trenty-eighth  of  July,  1981;  12  02:01  am 
Kyla  O'Shea 

Tha  Grataful  Daad  j  The  new  default  is  nou’  cached  ] 

O'Shaa 

«>KYLE 

i'LOOK-AT-UNIT 
•'DEFAULT- UN IT -PRIM TER 


Daacription  Tha  daacription  of  KYLE  vaa  not  providad 

Prototype  {#>PERSON} 

Prototype  Of 

My  Creator  Kan  Haaaa 

My  File  Of  Definition  ARLO  SOURCES;  INQUIR  •  > 

My  Tima  Of  Creation  Saturday  the  trenty-eighth  of  July,  1981;  12  02:01  am 
Full  Name  Kyla  O'Shaa 

Hacking  Tha  Grateful  Daad  '  The  new  default  is  nou’  cached 

Lett  Nana  O’Shea 

My  Naoa  *>KYLE 

My  To  Daacriba  Saif  »'LOOK-AT-UNIT 

My  To  Print  Saif  *' DEFAULT- UNIT -PR1N TER 

Paraonal  Name  Kyla 

Suparviaor:  {#>LEE} 

And  now  let  us  set  the  world  back  to  normal,  changing  Lie’s  Hacking  slot 
once  more  and  reinstating  the  old  value  on  Kyle. 


Editing  {*>KYLE}  >>Edit 

Uhich  alot  of  {*>KYLE}  vould  you  lika  to  edit’Lee 
"Lee1  '  ian't  tha  name  of  a  defined  alot 

We  accidently  referred  to  the  unit  to  edit,  instead  of  the  slot  of  Kyle  we 
wished  to  edit.  Fortunately,  the  unit  editor  was  clever  enough  to  uiarn  us  of  our 
mistake,  but  not  clever  enough  to  see  through  it. 


v'  •  - 


-v  a 


/.v 
'  -  '  ■ 
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Did  you  make  •  aistakeMY  or  II)  Yes 

'..'hich  «lot  of  (#>KYlE)  would  you  like  to  edit7Supervisor 
Editing  {#>LE£}  >>Sot 

L’hieh  olot  of  {#>LEE}  would  you  like  to  eef’Hacking 

v.'h»t  would  you  like  in  the  Hacking  elot  of  {#>LEE}7Engineering  Design 
Editing  {*>LE£}  >>Quit 
Finished  editing  {f>L£E} 

I  The  world  should  be  back  to  normal  now... 


Editing  {#>KYLE}  >>G  --  Describe  Slot  Value 

V.'hich  elot  of  {#>KYLE}  would  you  like  to  eee’Hacking 

The  Hacking  slot  of  {*>KYLE}  is  Engineering  Deaign 

[ ^^“AndwuieedUi^. . 


This  is  justified  by 

The  Hacking  slot  of  {*>LEE}  is  Engineering  Design 

The  To  Get  Value  slot  of  {«>HACKII!G}  is  S' TYPED -DEFAULT IUG-CET 

The  Supervisor  slot  of  {#>KYLE}  is  {#>LEE} 

The  To  Get  Value  slot  of  {#>SUPERVISOR }  is  #  ’  TYPED-DEFAULTI I1G-GET 
The  To  Default  Value  olot  of  {*>HACKI1!C}  is 

#> IHHERI T- THROUGH- SUPERVISOR- OR -ARLQ  ASK-USER-FOR- SLOT- OR-ELSE 

The  To  Get  Value  slot  of  {#>T0 -DEFAULT -VALUE}  is.  »■  TYPED-DEFAULTI DG-CET 


Ken  Haase 


3.6.3  Other  slots 

Editing  {#>ITLE}  >>Nev  unit 
V.'hat  unit  would  you  liko  to  edifAlice 
Description  of  the  ARLO  unit  {*>ALICE} 

Doacnption  Tho  doncnption  of  ALICE  won  not  provided 

Prototype  {*>PERS0!l} 

Prototype  Of 
My  Creator  Ken  Haase 

My  File  Of  Definition  ARLO  SOURCES;  ItlQUIR  »  > 

My  Time  Of  Creation  Saturday  the  twenty-eighth  of  July.  1984,  12  02  02  am 
Full  Haas  Alice  Ideas 

Last  Haas  Adaaa 

Fly  Haas  OALICE 

My  To  Describe  Self  i’LOOK-AT-UNIT 

My  To  Print  Self:  » 'DEFAULT-UtilT-PRinTER 

Personal  Haas:  Alice 

Editing  {«>ALICE}  >>G  --  Daacribe  Slot  Value 

V.'hich  slot  of  {#>ALICE}  would  you  like  to  aee,Working  In  Field 


~ho  it  Alice  hacking  for’Rodgers 

The  forking  In  Field  slot  of  {*>AL1CE}  is  Eaotional  Analosge  Robots 

j  And  again,  ARLO  provides  the  dependencies  of  the  computation: 


This  is  justified  by 

The  Hacking  slot  of  {*>R0DCERS}  is  Eaotional  Analouge  Robots 
The  To  Cat  Value  slot  of  {#>HACKI1.’C}  is  f  '  TYPED  -DEFAULT  1  ’.'G- GET 
Th*  Supervisor  slot  of  {*>ALICE}  is  {«>R0DCERS} 

The  To  Get  Value  slot  of  {«>SUPERVISOR  }  is  * ' TYPED -DEF  AULTI : C-CET 
The  To  Default  Value  slot  of  {#>'J0RKIL'C-  IL- FIELD }  is 
»>THE-VALUE-0F-TH£-HACKI!:G-0F-THE-SUPERVIS0R-0F 

The  To  Get  Value  slot  of  {»>TO-DEFAULT -VALUE}  is  *  '  TYPED -DEF  AULT  I  ::C-GET 

Finally,  wt  ask  for  Alice 's  de scription  again,  to  see  that  the  appropriate  slot 
has  been  cached  on  the  unit  descnpition. 


ARLO 
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Editing  {#>ALICE}  >>Descnbe  [Describes  the  umt  .  j 
Description  of  the  ARLO  unit  {#>ALICE} 

Description  The  description  of  ALICE  was  not  provided 

Prototype  {f>PERSQU} 

Prototype  Of 

My  Creator  Ken  Haase 

My  File  Of  Definition  ARLO  SOURCES,  INQUIR  ‘  > 

My  Time  Of  Creation  Saturday  the  twenty- eighth  of  July,  198-.  12  ('2  02  run 

Full  lame  Alice  Adame 

Last  .‘iame  Adams 

My  Name  #>ALICE 

My  To  Describe  Self  • 1 LOOK-AT-UNIT 

My  To  Print  Self  # 'DEFAULT- UII IT -PRINTER 

Personal  V. ame  Alice 

Supervisor  {#>R0DGERS} 

..'orking  In  Field  Emotional  Analouge  Robots  ( The  value  has  been  cached 

Editing  { # > A L I CE }  >>Quit 
Finished  editing  {#>ALICE} 


ARLO 
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3.6.4  Errors 

Beck  to  editing  {*>KYLE} 

Editing  {#>KYLE}  >>G  --  Describe  Slot  Veins 

Y/hich  slot  of  {#>XYL£}  would  you  like  to  see^Wedging 

If  you  remember  the  definition  on  page  SI,  this  slot  has  a  deflation  which 
“defaults”  by  referring  to  itself  again.  Attempting  to  get  this  slot  from  a  unit  will 
recurse  fatally  if  a  value  isn’t  already  available.  (In  which  case  that  value  would 
simply  be  returned .)  Let’s  watch  sparks  fly. 


>>ARL0-Error  I  seem  to  be  fetelly  recnriing  on  getting  the  Hedging  slot  of  {#>XYLE} 
(Hhile  getting  the  Hedging  slot  of  {OKYLE}) 

A  description  of  the  current  slot  operation  being  attempted  is  always  provided 
to  the  user  when  she  is  asked  to  handle  an  ARLO  condition. 


CET-VALUE 

Arg  0  (IH-UII IT) 
Arg  1  (OF-SLOT) 
s-A.  (RESUME] 
s-B.  c-r 
s-C.  (ABORT] 
e-D 
s-E 


{#>KYLE} 

{#>VEDGIKC} 

Perform  the  operetion  using  subprimiti vet 
Print  out  the  current  etete  of  ARLO's  computetions 
Return  to  the  examining  the  unit  {#>XYLE} 

Return  to  Dribbling  Lisp  Listener 
Return  to  Lisp  Top  Level  in  Liep  Listener  1 
->c-7  Print  out  the  current  state  of  ARLO'e  computations 
ARLO  ie  currently 

3  getting  the  Hedging  slot  of  {*>KYLE} 

2  '..'hile  trying  to  compute  a  default  for  the  Hedging  slot  of  {*>XYLE} 

i  while  getting  the  Hedging  slot  of  {*>KYLE} 

I  This  is  the  trace  produced  by  the  l.'HERE  function. 


->  [RESUME]  Perform  the  operation  using  subprimitives 

The  subprimitives,  unfortunately,  merely  return  NIL  if  a  slot  doesn’t  exists. 
Since  Kyle  has  no  'Hedging  slot,  the  value  NIL  is  computed  as  one.  But  the 
'/.'edging  slot  requires  -  as  it  is  defined  on  page  SI  -  a  string  and  ARLO  complains 
about  this  inconsistency. 
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>>ARLO-Condition  The  Wedging  slot  cannot  accapt  the  value  NIL 
(it  isn't  of  type  STRING- TYPE) 

'i'hile  caching  NIL  on  the  hedging  elot  of  {#>KYL£} 
#>SLOT-VERIFIER-FOR-CEDGING: 

Arg  0  (UNIT)  {#>KYL£} 

Arg  1  (SLOT)  {#>«EDCI»G} 

Arg  2  (VALUE)  NIL 


e-A , 

a-B. 

e-C, 

e-D 

e-E 


[RESUME] 


[ABORT] 


Accept  the  value  anyvay 

Print  out  the  current  state  of  ARLO ’a  computations 
Return  to  the  examining  the  unit  { *> K YLE } 

Return  to  Dribbling  Lisp  Listener 
Return  to  Lisp  Top  Level  in  Lisp  Listener  1 
->c-?  Print  out  the  current  state  of  ARLO'e  computations 
ARLO  is  currently 

2  caching  NIL  on  the  Cadging  slot  of  {t>XYL£} 

1  chile  getting  the  Cadging  elot  of  {f>XYL£} 

->  (RESUME]  Accept  the  value  enyvay 


And  finally  we  get  a  final  result,  after  all  of  our  running  around  m  the  error 
system. 


The  Cadging  elot  of  {*>KTLE}  is  NIL 
This  ia  justified  by 

The  Functional  Value  elot  of  {»>DESCRIPT1011-OF-CEDGE}  ia 
f <DTP- COMPI LED- FUNCT ION  CEDCE  2101#7«2> 

The  To  Default  Value  elot  of  {OVEDCING}  is  I'CEDGE 


ARLO 
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3.6.5  Shadowing  Definitions 

Editing  {#>KTLE}  >>Nev  unit 

What  unit  vould  you  liks  to  edit’  Brian 

Description  si  tha  1RL0  unit  {#>BRIA11} 


Description 
Prototype 
Prototype  Of 
My  Creator 

My  File  Of  Definition 
My  Time  Of  Creation 
Full  Haas 
Last  Haas 

My  naae: 

My  To  Daacribe  Saif: 
My  To  Print  Self : 
Personal  Naas: 
Supervisor: 


The  description  of  BRIAN  vaa  sot  provided 

{#>SII1HER} 

Kan  Heal a 

mo  sources,  iihjuir  •  > 

Saturday  the  tventy-aighth  of  July.  1984,  12  02:02  am 
Brian  Walking-Song 
talking- Song 
OBRIAH 

•  •LOOI-iT-OllIT 

#'  DEFAULT-  Ull  I T  -PRI II  TER 

Brian 

{#>CHAB0} 


Here  we  ask  for  the  hacking  slot  of  Brian,  whose  prototype  is  Winner.  A.' 
defined  initially,  the  Winner  prototype  provides  a  different  definition  of  Hacking 
from  the  default.  Precisely,  it  asks  the  user  for  the  hacking  slot  directly,  rather 
than  first  trying  to  inherit  it  through  the  Supervisor  relation. 


Editing  {OBRI1II}  >>G  --  Daacribe  Slot  Value 

Which  slot  of  {f  >BRIA'I }  vould  you  like  to  aeeTHacklng 

Whet  ie  Brian  hacking’lntelligent  Mystic  Systems 

The  Hacking  slot  of  {#>BRIA1I}  is:  Intelligent  Mystic  Syetaaa 

This  is  justified  by  Ken  Haase  said  so 

This  citation  -  referring  to  myself,  tke  person  using  the  program  -  ts  recorded 
by  a  dependency  record  which  is  a  SLOT-CITATIOH-RECORD,  documented  in  Section 
2.2.1. 
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Editing  {#>BRIAN}  >>Describe  [Describes  the  unit 
Description  of  the  ARLO  unit  {#>BRIAN} 
Description  The  description  of  BR! 

Prototype  {#>“IIIHER} 

Prototype  Of 

Sty  Creator  Ken  Haase 

Sty  File  Of  Definition  ARLO  SOURCES.  111QUIR 

Sty  Time  Of  Creation  Saturday  the  tventy-ei 

full  llame  Brian  Talking-Song 

Hacking.  Intelligent  Siovie  Syst 

Laat  Name  talking- Song 

Sty  Name  f>BRIAtl 

Sty  To  Describe  Self  fLOOK-AT-UHIT 

Sly  Io  Print  Self:  #’ DEFAULT- UNIT -PRINTEI 

Personal  Name  Brian 

Supervisor  {#>CHAR0} 


The  description  of  BRIAN  was  not  provided 
INNER  } 

Ken  Haase 

ARLO  SOURCES.  111QUIR  *  > 

Saturday  the  tventy-eighth  of  July,  1984.  12  02  02  :mi 
Brian  Talking-Song 

Intelligent  Siovie  Systems  |  The  value  has  been  cached  \ 

talking- Song 

OBSIAI1 

•’LOOK-AT-UHIT 
f  ■DEFAULT-UNIT-PRINTER 
Brian 
{#>CHARO} 


Let’s  look  at  where  Brian’s  description  got  its  replacement  hacking  definition 
-  which  asked  us  for  a  value  directly  -  from.  The  shadowed  definition  of  hacking 
you  remember  -  from  Page  SP  -  looks  on  the  prototypes  of  the  unit  it  is  accessing. 
So  we  edit  the  prototype  of  #>BRIAIi.  .. 


Editing  {#>BRIAN}  >>Edit 

Thieh  slot  of  {*>BRIAN}  vould  you  like  to  edit7Prototype 
Deecription  of  the  ARLO  unit  {#>V?INNER} 


Description 
Prototype 
Prototype  Of 
My  Creator 

Sly  File  Of  Definition 
My  Time  Of  Creation 

Sty  Name 

My  Specific  Type 
My  To  Describe  Self 
My  To  Print  Self 
Shadoved  Hacking  Definition 


Somone  sho  doesn't  alrays  follow  their  supervisor 
{»>PERSOH} 

{OBRIAN  } 

Ken  Haase 

ARLO  SOURCES,  INQUIR  •  > 

Saturday  the  twenty- eighth  of  July,  1984,  12  02:00  nm 
#> TINNER 
{OTINNER-  TTPE) 

# ’ LOOK-AT-UNIT 
# 'DEFAULT-UNIT-PRINTER 
{#>HACKINC-0} 

[ And  here  is  the  shadowed  definition  o]  Hacking  ] 


Wc  can  look  deeper  into  this  new  definition  of  hacking  by  editing  its  descrip¬ 
tion.  Every  ARLO  slot,  since  it  is  explicitly  described  in  ARLO,  is  accessible  in 
this  way. 
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Editing  {•>BR'lili}  >>Edit 

Shich  (lot  of  {*>811113}  vould  you  like  to  adit?  Shadowed  Hacking  Definition 
Description  of  ths  ARLO  slot  {*>H»CXIHC-0} 


Description 
Prototype 
Prototype  Of 
To  Default  Value 
Make*  Sense  For 
Data  Type 
My  Creator 

My  File  Of  Definition 
My  Tine  Of  Creation 
Actual  Cat  Value 

My  To  Deecribe  Self 
My  To  Print  Self 
To  Cache  Value 
To  Describe  Value 
To  Get  Value 
To  Help  Find  Value 
To  Print  Valua 
To  Prompt  For  Value 
To  Head  Value : 


The  description  of  HACKI11G-0  van  not  provided 
{*>HACKinC} 

ASK-USER-FOR-SLOT 

{*>*'I1IKER-TYPE} 

{*>STRIMG-TYPE} 

Kan  Haaee 

ARLO  KBaeea,  INQUIR  BIN  NEWEST 
Saturday  the  sixth  of  April,  1985;  9.11:58  am 
•CHECK -VALUE 
•>HACXinG 
* '  LOOK-AT- SLOT 

•  'DEFAULT- UNIT -PR 13  TER 

•  TYPED-CACHE 

(LAMBDA  (IC1I0RE)  IGNORE) 

•  typed-defaulti:;g-cet 

•EVAL-READ-AS-ESCAPE 

•GPRXKTC 

• ' CUTE-PROMPT- FOR- VALUE 

•  READLIIIE 


To  Verify  Type 

•  'CORE  imjUIR  SLOT-VERIFIER-FOR-HACKIKG-O 
Editing  {»>HACKIHC-0}  »Quit 
Finished  editing  {•>HACKIIIC-0} 

Editing  {*>VINIIER}  »0uit 
Finished  editing  {»>”I!J!!ER} 

Editing  {•>BRIAt! }  >>Quit 
Finished  editing  {oBRIA'.i} 

Back  to  editing  {•iKYLE} 
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3.6.6  Modifying  our  language 

Editing  {OKTLE}  >>Nev  amt 

Shat  nnit  would  you  like  to  edit?Alice 

Description  of  the  ARLO  unit  {OALICE} 

Description  Thn  doncription  of  ALICE  was  not  provided 

Prototype  {OPERSOU} 

Prototype  Of 

Hy  Creator  Ken  Hanne 

My  File  Of  Definition  ARLO:  SOURCES;  INQUIR  •  > 

My  Tiae  Of  Creation 

Saturday  the  twenty-eighth  of  Inly,  1084;  12:02:02  am 
Editing  {OALICE}  >>Describe  [Describes  the  urn!  ] 

Deecription  of  the  ARLO  nnit  {OALICE}: 

Deacription:  The  deecription  of  ALICE  was  not  provided. 

Prototype:  {OPERSOU} 


Ken  Haase 


Deacription : 
Prototype: 

Prototype  Of 
My  Creator 

My  File  Of  Definition 
My  Time  Of  Creation: 
Full  llama: 

Last  Hams: 

My  llama 

My  To  Describe  Self 
My  To  Print  Self: 
Personal  llama: 
Supervisor: 

Working  In  Field. 


Ken  Haase 

ARLO:  SOURCES;  IUQUIR  *  > 

Saturday  the  tv/enty-eighth  of  Inly,  1984,  12  02  02  am 

Alice  Adame 
idama 

OALICE 

#'L00K-AT-UliIT 
t ‘DEFAULT- UNIT -PRINTER 
Alice 

{ORODGERS} 

Emotional  Analouge  Robots 

[  This  is  the  value  defaulted  earlier  in  the  example  ( Section  S  6.  S,  Page  fS) 
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Editing  {*>ALICE}  >>Ne»  unit 

i'het  unit  could  you  like  to  edit’Working  in  Field 
Deaeri ption  of  the  ARLO  «lot  {*>!?ORKIHG-in-FIELD} 

Doncnption  Thin  m  thn  field  n  pnrnon  it  corking  in 

Prototype  {*>PERS0tl-SL0T } 

Prototype  Of 
To  Default  Value 

»>THE-VALUE-OF'THE-HACKINC-OF-THE-SUPE*VISOA-OF 


Makee  Senee  For 
Data  Type 
My  Creator 

My  File  Of  Definition 
S!y  Ti»e  Of  Creation 
Actual  Get  Value 
High  Level  Definition 
My  t.’ame 

Sty  To  Detente  Self 
My  To  Print  Self 
To  Cache  Value 
To  Detcnbe  Value 
To  Get  Value 
To  Print  Value 
To  Proceee  Slot 
To  Verify  Type 


{«>PERSO!I-TYPE} 

{#>STRIMC-TYPE} 

Ken  Haaee 

ARLO  SOURCES.  Il.’QUIR  •  > 

Saturday  the  tventy-eighth  of  July.  1984,  12:01  58  am 
•CHECK-VALUE 

•  CORE  IIIQUIR  THE- VALUE- OF- THE-HACXING-OF-  THE- SUPERVISOR -OF 
•iSORKINC- IN -FIELD 

•■LOOK-AT-SLOT 
•'DEFAULT-UKIT -PRINTER 
•TYPED-CACHE 
(LAMBDA  (IGNORE)  IGNORE) 

* ' TYPED-DEFAULTINC-GET 
•GPRINTC 

••DEFAULT-PROCESS-SLOT 

•  'CORE  IIIQUIR  SLOI-VERIFIER-FOR-'JORXINC-IH-FIELD 


We  define  the  new  defaulting  method  by  using  the  automatic  coder  SLOT-COMPOSJTIOII. 
Just  as  we  defined  #>HACKING-0,  we  define  the  new  «>Y!C1RKIHG- III -FIELD  (o  inherit 
from  the  #>HACKIHG  slot  two  supervisors  away . 
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Editing  {#>S0RKI1IG-IN-FIELD}  »Set  Slot  Vain* 

ffhieh  alot  of  {#>«ORKItIG-I!I-FIELD}  would  you  like  to  adit’  To  Default  Value 
Shat  value  would  you  Ilka  in  the  {#>To-Def eult- Value }  alot  of  {iiSORKING-IH-FIELD} 
(Slot-Compoeition  (liat  *>Hacking  #>Suparviaor  #>Supervieor )) 

Editing  { #>'i'0RK  INC -IN- FIELD}  »Daacnba 
Oaacription  of  the  ARLO  alot  {»>SORKIHG-IU-FIELD} : 

Oaacnption  Thia  ia  the  field  a  paraon  la  working  in 

Prototype  {#>PERS0!I -SLOT  } 

Prototype  Of 
To  Default  Value 

#>THE-VALUE-OF-THE-HACKIUG-OF-THE-SUPERVISOR-OF-TH£-SUPERVISOR-OF 
Makea  Sanaa  For  {#>PERSON-TYPE} 

Data  Type  {#>STRIHG-TYPE} 

My  Creator:  Kan  Haaaa 

My  File  Of  Definition:  ARLO  SOURCES:  IlIQUIR  •  > 

My  Tina  Of  Creation  Saturday  tha  twenty-eighth  of  July,  1984,  12:01:58  am 
Actual  Gat  Value:  *'CHECK-VALUE 

High  Level  Definition 

*  '  CORE  I1IQUIR  THE-VALUE-OF-THE-HACKUIG-OF-THE-SUPERV I SOR- OF- THE -SUPERVISOR  -  DF 
f  The  new  high  level  definition,  ail  cominled  .  ] 

My  Naae  *>S0RKING-I1I-FIELD 

My  To  Deacribe  Self  #'LOOK-AT-SLOT 

My  To  Print  Self  # '  DEF  AULT  -  U1II T  -PR1 0  TER 

To  Ca.he  Value  # ' TTPED-CACHE 

To  Decacha  Value  » 'REMOVE- VALUE 

To  Deacribe  Value:  (LAMBDA  (IC110RE)  IGNORE) 

To  Get  Value  t ’ TTPED-DEFAUL TIHC-GET 

To  Print  Value  #'GPRINTC 

To  Proceaa  Slot  # 'DEFAULT-PROCESS-SLOT 

To  Verify  Type 

f  ’CORE  I1IQU IR  SLOT- VERIFIER-FOR-SORK TNG- Ill- FIELD 
Editing  {#>'.. ORKING- IN- FIELD}  >>Quit 
Fmiahed  editing  {#>'..ORK IBG- IH- FIELD } 

Back  to  editing  {#>ALICE} 

Since  wt  changed  the  way  V.'orking-In-Field  is  defined,  any  valve s  uihich 
were  defaulted  in  the  old  way  should  be  invalidated.  Let’s  look  back  to  Alice’s 
description  to  see  if  this  is  indeed  the  case. 
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Editing  {*>ALICE}  >>Detcribe 
Description  of  tho  ARLO  unit  {#>ALICE} 


Description 
Prototypo 
Prototypo  Of 
My  Creator 

My  Filo  Of  Dofinition 
My  Time  Of  Creation 
Full  Nano: 

Laot  Ham 

My  Ham: 

My  To  Doocnbo  Self : 
My  To  Print  Self: 
Personal  Ham: 
Supervieor 


Tho  description  of  ALICE  vat  not  provided 
{#>PERS0H } 

Ken  Haase 

ARLO  SOURCES,  IHIJUIR  *  > 

Saturday  the  tventy-eighth  of  July,  1084,  12:02:02  am 

Alice  Adam 
Adam 

*>ALICE 

8 ' LOOK-AT-UHIT 

#’ DEF AULT- UHIT-PRIN  TER 

Alice 

{»>R0DCERS} 

| And  the  cached  forking-In-Field  has  indeed  disappeared  J 


Let’s  regenerate  it. 


Editing  (#>AL1CE)  >>G  --  Describe  Slot  Value 

fhleh  slot  of  {#>ALICE}  would  you  like  to  see?  Working  In  Field 
The  forking  In  Field  slot  of  {*>ALICE}  ie  Robots 

You  can  see  from  the  justifications  of  the  value  that  it  did  the  right  thing, 
looking  at  Rodger’s  supervisor  and  getting  her  Hacking  slot. 


This  ie  justified  by: 

The  Hacking  slot  of  {*>CALVI11}  it  Robote 

Tho  To  Cot  Value  slot  of  {OHACXIHG}  it  t '  TTPED -DEFAULTI Hfl-GET 

The  Supervisor  slot  of  {f>R0DGERS}  ie  { •>CALVIII } 

Tho  Supervieor  slot  of  {#>ALICE}  ie:  {#>R0DGERS} 

The  To  Get  Value  elot  of  { OSUPER  VISOR }  is:  » ’ TYPED-DEFAULT I NG-GET 

The  To  Default  Value  elot  of  {f >SORKIHG-IH-FIELD}  is 

«>THE-VALUE-OF-THE-HACKI!IG-OF-THE-SUPERV1SQR-OF-THE-SUPERVISOR-DF 

The  To  Got  Value  elot  of  {#>TO-DEFAULT- VALUE}  it  t ' TTPED -DEF AULT I HG-GET 

And  finally,  we  check  that  the  value  we  have  generated  has  been  appropriately 
cached... 
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Chapter  4 

An  Example:  Introspection 


This  chapter  describes  an  automatic  explanation  system  —  implemented  in  and  for  ARLO  —  that  examines 
a  collection  of  ARLO  units  and  generates  a  structured  English  explanation  of  them.  These  units  would 
typically  describe  some  particular  domain  or  embedded  representation  language,  and  be  organized  to  aid 
users  or  programmers  introducing  themselves  to  the  domain  or  language.  The  system  analyzes  a  collection  of 
units  by  trying  to  extract  their  salient  features  as  an  organizational  focus  for  its  explanation.  Unfortunately, 
since  the  text  it  generates  is  primitively  template  driven  (currently),  the  system  does  not  —  at  this  time  — 
use  these  extracted  features  as  the  focus  for  discourse  or  individual  explanations. 

This  is  an  example  of  the  sort  of  general  self-referential  facility  which  users  may  implement  in  ARLO. 
With  something  comparable  to  this  explanation  system,  a  user  need  merely  point  at  some  collection  of 
units  and  ask  “Explain  this”  to  acquire  an  organized  explanation  capturing  whatever  special  “observable” 
structure  the  units  possessed. 

4.1  Explanation  Structures 

The  explanation  system  takes  the  collection  of  units  handed  to  it.  and  generates  another  set  of  units  called 
an  ezplanntxon  slructurt  describing  them.  This  structure  is  a  hierarchy  of  explanations,  each  level  of  which 
partitions  the  set  of  units  over  one  of  a  number  of  possible  relationships.  These  possible  relationships  are  the 
possible  structural  slots  of  a  given  explanation,  and  defaults  to  the  union  of  a  collection  of  system  defaults 
and  the  slot  descriptions  in  the  set  of  units  being  explained. 

The  explanation  process  takes  the  set  of  units  being  explained  and  generates  a  partion  of  it  for  each 
structural  slot.  The  resulting  partitions  —  one  over  each  structural  slot/relation  —  are  then  compared, 
and  the  slot  whose  partition  contains  the  largest  subgroups  is  selected  as  the  focus  of  the  explanation.  The 
intuition  this  supports  i.-  that  the  organizational  focus  for  an  explanation  of  some  collection  of  units  should 
be  the  relation  which  organizes  those  units  into  the  biggs!  “chunks”.  If  a  user  doesn’t  like  the  partition  chose 
at  one  level  though.  I  lie  explanation  structure  can  be  direct  1)  altered  to  focus  on  another  divisive  relation. 
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For  each  of  the  subgroups  in  t lie  partition  selected,  a  sub  explanation  is  general  -d.  whose  relevant  units 
are  the  elements  of  the  subgroup,  and  whose  structural  slots  are  inherited  from  the  original  explanation, 
modulo  t  he  slot  part  itioned  over.  The  explanation  mechanism  then  recurs  on  t  lie>e  stib  ex  pi  an  at  ions,  stopping 
when  the  section  si: e  the  number  of  units  being  explained  by  a  given  chunk  of  structure  drops  below 
some  explanation-wide  threshold  for  specialization  of  sections. 

The  explanation  structure  produced  by  this  process  may  then  be  passed  to  a  text-generator,  a  graphical 
exploration  environment,  or  even  a  theory-making  mechanism  trying  to  classify  regularities  among  generated 
or  accumulated  ARLO  structures. 

4.2  Textual  Generation 

Textual  generation  from  the  explanation  structure  currently  produces  organized  and  formatted  15  output, 
appropriately  sectionized  and  structured  so  as  to  produce  readable,  structured  output.  On  both  the  level 
of  describing  individual  units  and  organizing  explanations  into  sections,  the  documentation  process  is  data- 
directed  by  reference  to  descriptions  in  ARLO. 

For  individual  units,  their  english  explanation  is  provided  by  calling  a  LISP  function  on  the  unit’s 
#>:ty-Scribe-To-Document -Self  slot,  which  is  inherited  (by  default)  over  the  #>Prototype  relation.  (Of  course 
this  inheritance  mechanism  may  be  shadowed  arbitrarily.)  These  inherited  description  functions  will  produce 
useful  for  human  consumption  —  descriptive  text.  Slot  definitions,  automatically  coded  LISF*  functions. 
ARLO  codtrs.  and  user  defined  functions  are  all  described  in  different  ways  so  as  to  provide  appropriate 
information  to  the  user.  In  a  more  advanced  form,  the  documentation  system  might  take  into  account 
interests  of  the  user,  information  already  related,  and  “trivial”  aspects  of  the  description  (for  instance, 
expected  colors,  planets,  languages,  etc). 

For  every  node  in  the  explanation  structure  which  has  a  relational  focus  —  which  partitions  a  set  of 
units  over  some  particular  slot  —  the  manner  of  sectionization  (determining  section  titles,  order  of  sections, 
discourse  restrictions  of  sub-sections,  etc)  is  determined  by  the  slot  being  partitioned  over  (taken  as  the 
organizational  focus  of  the  explanation).  For  instance,  relations  which  are  posited  by  the  user  as  hierarchical 
*'  ate  ordered  into  sections  by  a  breadth  first  enumeration  of  the  hierarchy  they  define.  Other  slots  may 
organize  their  documented  partitions  on  ages,  execution  speeds,  size,  or  frequencies  of  appearance  of  their 
associated  values. 

4.3  Graphical  Presentation 

The  explanation  structure  generated  by  the  system  can  also  be  hooked  up  to  a  graphical  interface  for 
examining  nested  structures.  Particularly.  ARLO’s  generated  explanation  structure  has  been  hooked  up 
to  the  Information- ,'aldo.  a  gestural  interface  for  manipulating  abstract  objects  in  an  information  space. 
This  information  space  is  constructed  of  interconnected  rooms  containing  objects  with  various  properties 

,'r'The  text  produced  is  either  formatted  for  the  terminal  or  (if  going  t  a  file)  for  some  appropriate  text  formatting 
program. 

'”\Ve  i  add  imagine  the  disc-very  -f  such  relational  properties  (like  being  hierarchical)  being  made  by  an  intel¬ 
ligent  program  generalizing  from  examples.  IC'ha83)  describes  a  system  which  does  just  this  sort,  of  relational 
.a-ii.  r  di/.oth  n  fr-m  examples  in  the  “world". 
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and  powers.  A  user  wields  the  information  waldo  to  explore  this  network  of  rooms  and  manipulate  theit 
contents,  moving  from  place  to  place  and  description  to  description  by  physically  immediate  gesture  and 
action . 

A  user  moves  a  hand  shaped  grip  across  a  flat  surface  to  move  a  hand  on  the  screen  and  "information 
waldo”  existing  in  an  abstract  "information  space”  from  location  to  location.  Stylized  gestures  of  grasping, 
pointing,  or  squeezing  are  detected  by  the  grip  and  cause  the  hand  on  the  screen  lo  manipulate  the  objects 
it  is  moving  among.  To  examine  an  ARLO  description  with  the  information  waldo,  you  merely  pick  up  the 
toll-shaped  description  and  squeeze  it:  its  relations  leap  out  from  its  body:  to  retract  a  lelation.  \ou  rub  out 
the  label  attaching  it  to  the  description;  to  move  from  one  room  to  another,  simply  put  your  hand  through 
an  open  door,  and  the  new  room  opens  itself  up  on  the  display.  This  gestural  interface  to  ARLO  is  used 
as  the  basis  of  an  explanation-based  browser  for  ARLO  structures.  Structured  explanations  ol  collections 
of  ARLO  units  are  used  in  the  design  and  construction  of  multi-room  museums  portraying  and  describing 
t  hem. 

The  explanation  structure  produced  for  ARLO  descriptions  can  generate  a  museum  of  the  units  ex¬ 
plained.  this  museum  consists  of  a  network  of  rooms  reflecting  the  connections  and  groupings  of  the  expla¬ 
nation  structure  A  user  exploring  some  particular  implementation  or  representation  with  this  facility  can 
use  spatial  metaphors  to  organize  her  understanding.  In  a  more  advanced  form,  a  sophisticated  interface 
would  design  the  museum  with  the  explicit  goal  of  providing  such  metaphors  and  mnemonic  arrangements. 
Figure  4-1  shows  the  museum  interface  being  used  to  explore  the  INQUIR  knowledge  base  of  the  previous 
example. 

4.4  An  Explanation  of  the  INQUIR  system 

The  following  is  an  automatically  generated  explanation  for  the  INQUIR  example  of  the  previous  chapter. 
It  was  produced  by  applying  the  above  explanation  system  to  the  in-core  implementation  of  the  INQUIR 
system  (determined  by  all  of  the  units  in  the  INQUIR  knowledge  base). 

These  units  are  best  organized  by  the  Prototype  relation. 

4.4.1  Units  without  any  prototype. 

Person  is  a  protypical  person  description  in  the  “INQUIR"  knowledge  base.  This  is  the  prototypical 
person . 

1.1.2  Units  with  a  prototype  of  Hacking 

Hacking  (as  defined  by  HACK  I  t!G  -  o)  is  a  slot  which  accepts  values  of  type  String  Type  and  makes  sense 
for  units  of  type  Winner  Typt.  The  description  of  HACKING-0  was  not  provided.  Its  value  defaults  by  the 
function  ARLO  Qt  "ESTION-<>,  which: 

Ask  the  usi  r  n  question  hy: 

(FORMAT  QUERY  IO  " What  is  a  hacking  on'”  (GET-VALUE  UNIT  #>PERSO::AL-::AME; 

■1.1. R  Units  with  a  prototype  of  Hand  Coded  Function 

Th'-r  unit-  : !  i  •  ■  be-i  organized  by  the  Prototype  n-lat  ion. 
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4.4.4  Units  without  any  prototype. 

Person  is  a  protypical  person  description  in  the  “INQUIR”  knowledge  base.  This  is  the  prototypical 
person. 

4.4.5  Units  with  a  prototype  of  Hacking 

Hacking  (as  defined  by  HACKING-o)  is  a  slot  which  accepts  values  of  type  String  Type  and  makes  sense 
for  units  of  type  Winner  Type.  The  description  of  HACKING-0  was  not  provided.  Its  value  defaults  by  the 
function  ARL0:Ql!ESTI0N-6,  which: 

Ask  the  user  a  question  by: 

(FORMAT  QUERY-10  “ What  is  a  hacking  on?”  (GET-  VALUE  L 'NIT  #>PERS0!IAL-HAHE; 

4.4.6  Units  with  a  prototype  of  Hand  Coded  Function 

DATA-TYPE-GENERATOR  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (UNIT  SLOT),  and  is 
documented  as:  “ Looks  through  the  prototypes  of  a  slot  for  its  data  type”. 

DEFAULT-DESCRIPTIOH-GEIIERATOR  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (IN-UNIT 
IGNORE),  and  is  documented  as:  “This  generates  a  description  excuse  ”. 

FI'.iD-HACKlliG-SLOT  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (UNIT  IN-SLOT),  and 
is  documented  as:  “ Looks  for  a  replacement  hacking  definition  in  a  persons  prototypes.”. 

GEnERATE-EXPLAllATI OU -TITLE  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (EXPLANA¬ 
TION  IGNORE),  and  is  documented  as:  “Generates  an  title  for  a  given  explanation.”. 

TO-GEL'ERATE-LAST-MAME  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (UNIT  IGNORE), 
and  is  documented  as:  “ Extracts  a  person’s  last  name  from  her  full  name.”. 

T0-GE!.'ERATE-PERS01IAL-"AME  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (UNIT  IG¬ 
NORE),  and  is  documented  as:  “Extracts  a  person’s  first  name  from  her  full  name.”. 

'/.EDGE  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (UN  SL),  and  is  documented  as: 
“Recurses  infinitely.”. 

4.4.7  Units  with  a  prototype  of  Person  Slot 

Full-l  ame  is  a  slot  which  accepts  values  of  type  String  Typt  and  makes  sense  for  units  of  type  Person 
Type.  This  is  the  full,  formal  name  of  a  person.  Its  value  defaults  by  the  function  ARLO:QUESTION-3, 
which: 

Ask  the  user  a  question  by: 

(FORMAT  QUERY-10  “  PWhat  is  the  full  name  of  the  person  described  by  a '  ”  UNIT) 

Hacking  is  a  slot  which  accepts  values  of  type  String  Type  and  makes  sense  for  units  of  type  Person  Type. 
This  is  what  a  person  is  hacking  on.  Its  value  defaults  by  the  function  ARLO:TRY-AND-TRY-AGAIN-l, 
which: 

Tries  tv  compute  a  value  by  two  distinct  methods: 

Starches  through  the  CORE.1NQU1R SUPERVISOR  slots  of  n  vmt  for  a  valut . 


ARLO 


Ken  Haase 


Ask  the  user  a  question  by: 

(FORMAT  QVERY-IO  “What  is  a  hacking?”  ( GET- VALUE  UMT  #>PERS01IAL-!IAUE,) 

Last-IIane  is  a  slot  which  accepts  values  of  type  String  Type  and  makes  sense  for  units  of  type  Person 
Type.  This  is  the  last  name  of  a  person.  Its  value  defaults  by  the  function  ARLO:TO-GENERATE-LAST- 
NAME,  which: 

Extracts  a  person’s  last  name  from  her  full  name. 

Personal  -  Hame  is  a  slot  which  accepts  values  of  type  String  Type  and  makes  sense  for  units  of  type  Person 
Type.  This  is  the  informal  name  of  a  person.  Its  value  defaults  by  the  function  ARLO:TO-GENER ATE- 
PERSONAL-NAME,  which: 

Extracts  a  person’s  first  name  from  her  full  name. 

Supervisor  is  a  slot  which  accepts  values  of  type  Person  Type  and  makes  sense  for  units  of  type  Person 
Type.  This  is  the  supervisor  of  a  person.  Its  value  defaults  by  the  function  ARL0:QUEST10N-4,  which: 
Ask  the  user  a  question  by: 

(FORMAT  QUERY-IO  “  &Who  is  a  hacking  for?”  (GET- VALUE  UMT  #>PEBSOI!AJL-nAHEyl 
'/.'edging  is  a  slot  which  accepts  values  of  type  String  Type  and  makes  sense  for  units  of  type  Person 
Type.  This  breaks.  Its  value  defaults  by  the  function  ARLO:WEDGE,  which: 

Recurses  infinitely. 

Working- In-Field  is  a  slot  which  accepts  values  of  type  String  Type  and  makes  sense  for  units  of  type 
Person  Type.  This  is  the  field  a  person  is  working  in.  Its  value  defaults  by  the  function  THE-YALUE-OF- 
THE-HACKING-OF-THE-SUPERVISOR-OF,  which: 

Gets  the  COR E:1NQUIR :H ACHING  of  the  CORE:INQUIR  SUPERVISOR  of  some  unit. 

4.4.8  Units  with  a  prototype  of  Person 

These  units  are  best  organized  by  the  Supervisor  relation. 

4.4.8. 1  People  without  any  supervisor 

Susan  Calvin  is  working  on  Robots. 

4. 4. 8. 2  People  working  for  Susan  Calvin 

Alice  Adams  is  working  on  Robots  for  Susan  Calvin. 

Elizabeth  Charo  is  working  on  Cognitive  Fundamentals  for  Susan  Calvin. 

Pat  Lee  is  working  on  Engineering  Design  for  Susan  Calvin. 

Robert  Rodgers  is  working  on  Emotional  Analouge  Robots  for  Susan  Calvin. 

4. 4. 8. 3  People  working  for  Elizabeth  Charo 

Arthur  Pendragon  is  working  on  Fantasy  Games  for  Elizabeth  Charo. 

4  4.8.4  People  working  for  Pat  Lee 

Kyle  O’Shea  is  working  on  Engineering  Design  for  Pal  Lie. 
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4. 4. 8. 5  Units  not  classifiable  by  Supervisor 

Winner  is  a  protypical  person  description  in  the  “lNQUIR"  knowledge  base.  Somone  who  doesn’t 
always  follow  their  supervisor. 

4.4.9  Units  with  a  prototype  of  Slot 

Person-Slot  is  a  slot  which  accepts  values  of  type  Any  Type  and  makes  sense  for  units  of  type  Person 
Type.  This  is  the  prototypical  slot  which  attaches  to  people. 

4.4.10  Units  with  a  prototype  of  Shadow  Slot 

Sh&dovied-Hacking-Def  inition  is  a  slot  which  accepts  values  of  type  Slot  Type  and  makes  sense  for  units 
of  type  Slot  Type.  This  is  a  shadowed  definition  for  hacking.  Its  value  defaults  by  the  function  ARLO:FIND- 
HACK1NG-SLOT,  which: 

Looks  for  a  replacement  hacking  definition  in  a  persons  prototypes. 

4.4.11  Units  with  a  prototype  of  Type 

Person-Type  specifies  a  class  of  LISP  objects  which  are  classified  by  Unit-Type  and  which  additionally 
satisfy  the  predicate  TEST-s  (documented  as  “An  arhitanly  hairy  test  ”).  This  is  a  type  satisifed  by  any  unit 
inheriting  from  Person 

Vinner-Tyj-  specifies  a  class  of  LISP  objects  which  are  classified  by  Unit-Type  and  which  addition¬ 
ally  satisfy  the  predicate  PROTOTYPE-OF-'.'/KI'ER?  (documented  as  “ Checks  to  see  if  a  unit  inherits  from 
CORE.INQU1R:  WINNER  via  CO  REPROTOTYPE.  ”).  This  is  a  type  satisifed  by  units  inheriting  (via 
the  Prototype  relation)  from  the  unit  Winner. 

4.4.12  Units  with  a  prototype  of  Winner 

Brian  Walking-Song  is  working  on  Intelligent  Mystic  Systems  for  Elizabeth  Charo. 
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Chapter  5 

Conclusion 


The  preceding  chapters  may  have  seemed  like  an  attempt  to  ‘sell’  ARLO  as  a  panacea  for  all  one’s  rep¬ 
resentation  problems.  Unfortunately,  when  pushed  to  the  limit,  ARLO  broke  down  for  fairly  fundamental 
reasons.  This  conclusion  examines  those  reasons  and  presents  arguments  for  which  of  ARLO’s  ideas  are 
worth  keeping  in  new  implementations,  and  which  caused  basic  problems. 

The  version  of  ARLO  described  here  was  developed  largely  in  the  summer  of  1983  and  the  spring  of  1984. 
In  the  fall  of  1984,  a  discovery  program  implemented  in  ARLO  (Cyrano-0)  acheived  about  half  of  the  results 
of  AM  and  Eurisko  in  elementary  mathematics,  discovering  the  notion  of  number  and  synthesizing  operat  ions 
such  as  multiplication  over  numbers.  Due  to  an  insufficent  theory  for  the  representation  of  inverses,  the  step 
to  factorization  and  AM’s  subsequent  discoveries  in  elementary  number  theory  were  not  acheived.  However, 
this  work  did  reveal  some  fundamental  properties  of  discovery  programs,  which  are  described  in  jHaa8Gb\ 
At  the  same  time  that  the  initial  development  of  Cyrano-0  was  proceeding,  Dave  McDonald  and  his 
students  at  UMASS-Amherst  were  using  ARLO  as  the  representational  backbone  for  generating  English  text 
(using  McDonald’s  MUMBLE  jMcD83|)  for  an  ‘intelligent  encyclopedia.  This  work  is  described  in  |MP84l. 

Implementing  Cyrano-0  in  ARLO  revealed  a  variety  of  cumbersome  properties  of  ARLO:  in  the  late 
winter  and  early  spring  of  1985,  an  effort  to  reimplement  ARLO  was  undertaken.  The  key  points  of  this 
implementation  (in  particular  its  differences  with  respect  to  the  ARLO  described  here)  are  presented  below. 
A  manual  for  this  version  of  ARLO  is  available  as  iH.iact.a  .  Work  with  this  new  ARLO,  however,  revealed 
deep  problems  (for  purposes  of  automated  discovery  programs)  in  the  ‘frame-slot’  orientation  of  ARLO. 
These  problems,  broached  in  detail  in  |Ha:i8(.c;.  are  also  sketched  below. 

Despite  these  criticims,  many  of  the  ideas  behind  ARLO  are  still  neccessary  constituents  of  AI  languages. 
The  ability  to  refer  to  abstract  descriptions  of  properties  allows  programs  to  easily  use  meta-knowledge  in 
describing  their  own  constructions.  In  particular,  knowledge  about  the  semantic  restrictions  on  properties 
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5.1  Flaws  in  ARLO 

In  developing  Cyrano-0,  ARLO  was  found  cumbersome  for  a  variety  of  reasons.  Some  of  the  reasons  are 
endemic  to  RLL’s  in  general  and  will  be  described  in  Section  5.2,  others  are  particular  to  the  implementation 
described  in  the  preceding  chapters.  These  problems  are  the  topic  of  this  section. 

Most  of  the  problems  in  using  ARLO  were  not  real  problems  of  expressiveness;  since  a  user  could  encode 
arbitrary  patterns  of  .activity  into  LISP  procedures,  ARLO  was  arbitrarily  expressive  in  a  weak  way.  The 
problems  were  rather  problems  of  perspicuity;  in  order  to  say  certain  things  that  one  wished  to  say,  it  was 
neccessary  to  descend  into  LISP.  The  magic  grab-bag  of  LISP  extensions  became  a  cloak  over  the  operation 
of  the  system,  requiring  that  each  modification  and  analysis  module  have  special  properties  for  special  casing 
various  opaque  extensions  of  ARLO. 

This  problem  revealed  itself  in  two  particular  components  of  ARLO:  the  dependency  network  and  the 
accretion  of  slot  behaviours.  In  each  of  these,  the  usefulness  and  extensibility  of  the  module  was  hampered  by 
the  lack  of  sufficiently  explicit  representations  of  ARLO’s  implementation;  the  module  had  to  be  extensively 
special-cased  to  handle  opaquely  distinct  representational  constructs. 

5.1.1  Flaws  in  the  Dependency  Network 

The  dependency  network,  implemented  in  LISP  Machine  flavors,  suffered  from  a  variety  of  flaws.  Most  had 
to  do  with  the  opaqueness  of  the  dependency  implementation;  user  interface  utilities,  debuggers,  and  special 
network  updating  code  had  to  deal  with  the  vagaries  of  message  passing  in  LISP  as  well  as  ARLO’s  unit-slot 
representation.  There  was  also  the  familiar  crossbar  problem  of  introducing  new  sorts  of  dependencies;  in 
order  to  introduce  a  new  type  of  dependency,  it  was  neccessary  to  determine  the  interaction  of  the  new 
dependency  type  with  all  existing  dependency  types  and  tools.  The  standard  protocol  for  invalidation  helps 
this  process,  but  managing  details  is  still  difficult.  In  particular,  a  user  interface  must  special  case  its 
presentations  for  each  different  sort  of  dependency. 

The  general  result  of  these  opacities  in  the  dependency  network  is  the  same  as  opacity  anywhere;  a 
significant  increase  in  the  amount  of  LISP  code  and  programming  required  rather  than  a  modest  increase  in 
the  amount  of  specified  representation.  We  would  like  to  be  able  to  extend  and  use  the  dependency  network 
in  much  the  same  way  as  we  use  ARLO  units.  Unfortunately,  dependency  records  are  not  units  but  are 
special  purpose  LISP  data  structures  encumbered  with  methods  and  procedural  semantics  couched  in  LISP 
Machine  LISP. 

The  obvious  solution  to  this,  implemented  in  [Hnr>8C.aj,  is  to  make  dependency  records  into  units.  In 
|Haa86n]  the  values  of  slot«  may  actually  be  ‘value  descriptions’  which  go  through  another  level  of  interpre¬ 
tation  to  get.  ‘actual  values’,  but  which  provide  useful  information  about  the  status  of  the  value  (where  it 
came  from,  how  reasonable  it  is,  etc).  These  values  are  similar  to  the  ‘active  values’  of  Loops  |BS83)  CYC 
!LSP85j;  the  are  annotated  values  about  which  arbitrary  properties  may  be  stated  or  inferred. 

5.1.2  Flaws  in  Combining  Slot  Actions 

The  flaws  described  in  this  section  arise  from  ARLO's  answer  to  the  question:  “How  do  we  add  new  be¬ 
haviours  to  a  slot  or  type  of  slot”  In  ARLO,  the  way  to  add  behaviours  is  to  write  LISP  code  which  will 
execute  the  behaviours.  The  way  to  modify  behaviour-'  (much  simpler)  is  to  simply  use  one  function  instead 
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of  another  as  one  slot  of  the  abstract  slot  description  being  modified.  This  is  made  possible  by  the  use  of 
reflexive  operators.  For  adding  behaviours,  the  presence  of  reflexive  operators  makes  writing  general  code 
simpler;  we  may  simply  say  “do  the  inversion  side-effects  of  the  slot”  rather  than  having  to  specify  whatever 
particular  function  implements  “do  the  inversion  side-effects  of  the  MOTHER  slot.”  However  the  problem  is 
that  new  behaviours  —  specified  in  LISP  —  the  become  largely  opaque  to  the  other  behaviours  and  funct  ions 
of  the  system. 

The  one  point  where  this  problem  became  most  obvious  in  ARLO  was  in  attempting  to  maintain  a 
distinction  between  ‘syntactic’  and  ‘semantic’  information  about  slots.  For  instance,  to  implement  inaity- 
to-many  relations  with  slots,  the  values  of  slots  must  be  interpreted  as  multiple  values;  the  content  of  a 
slot  is  then  (say)  a  list.  But  the  semantic  restrictions  placed  on  a  slot  (properties  like  Makes-Sense-For  and 
Data-Type)  should  apply  to  the  individual  elements  of  the  list,  rather  than  the  list  itself.  This  distinction 
(neccessary  due  to  the  focus  of  ARLO  on  single-valued  slots17)  is  impossible  to  patch  by  using  prototype 
inheritance  for  abstraction,  for  we  wish  to  speak  of  semantic  AND  syntactic  inheritance.  Thus  we  can 
say  that  the  Children  slot  is  syntactically  a  set  and  semantically  only  accepts  human  beings  on  both  ends 
(as  attachement  and  value).  We  wish  these  properties  to  inherit  differently.  In  ARLO,  however,  this  was 
impossible. 

The  solution  to  this  particular  problem  in  |Haa86a]  is  to  simply  have  two  different  inheritance  relations 
and  two  distinct  levels  of  operation  for  fetching  slots:  an  implementation  level  of  accessing  a  slot  and  an 
interpretation  level  of  getting  slots.  The  first  level  is  a  ‘syntactic’  level;  the  second  level  is  ‘semantic.’ 

This  solution  is  effective  but  introduces  some  problems  of  its  own.  In  particular,  though  we  would 
like  ‘syntax’  and  ‘semantics’  to  be  orthogonal,  they  turn  out  not  to  be.  When  a  new  syntactic  or  semantic 
primitive  is  introduced  into  the  language,  provision  must  often  be  made  in  the  ‘other  half’  of  the  implemen¬ 
tation.  This  is  better  than  in  the  implementation  described  in  this  document,  (where  adding  a  non-primitive 
construction  involves  combining  LISP  code  from  several  places)  but  still  not  ideal.  An  argument  that  this 
problem  is  endemic  to  RLLs  is  offered  in  Section  5.2. 

5.2  Why  RLL’s  are  no  good 

All  of  the  problems  described  in  the  previous  section  arise  from  the  opacity  of  extensions  to  the  RLL  These 
opacities  result  from  the  inclusion  of  arbitrary  LISP  code  in  the  specification  of  slot  behaviours.  Ir.  each  case, 
in  (HaaftO.y  the  problem  was  resolved  by  factoring  out  the  LISP  code  into  primitives  in  the  representation. 
Thus  the  methods  for  handling  dependency  propogation  were  assigned  to  properties  of  value  descriptions  and 
the  distinction  between  syntactic  specification  and  semantic  specification  moved  from  implicit  specification 
in  LISP  code  to  a  distinction  between  hierarchies  in  the  representation.  We  might  hope  that  given  enough 
such  migrations  —  that  the  right  ‘primitives’  would  be  found  to  avoid  any  need  to  escape  to  LISP. 

I  nfort unately,  we  already  know  —  in  some  sense  —  what  this  ‘right’  set  of  primitives  should  be:  it's 
called  a  programming  language  Psers  of  RLLs  are  forced  into  LISP  (and  therefore  weaken  the  utility  of  the 
RLL)  when  they  need  to  do  something  which  the  RLL  (as  given)  cannot  adequately  express.  .4  fufficcntly 
powerful  RLL  is  a  full-fledged  programming  language.  It  must  be  -  however  a  programming  language 

17ARLO  might  tie  criticized  fir  this  basic  assumption,  hut  the  problem  is  that  any  basic  assumptiui  of  the  lan¬ 
guage  may  be  ' -h ■  rt  cirruited'  nly  by  descending  bit--  the  murky  •  ■paquenes-  ->f  LISP  c.-de. 
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which  has  a  manipulable  and  perspicuous  representation  of  itself.  ‘Limited  RLLs,’  like  ARLO  and  the 
language  described  in  (Haa86aj,  are  useful  for  particular  applications  but  eventually  lose  generality  when 
users  require  the  full  power  of  a  programming  language.  For  instance,  slots  defining  individual  slot  actions 
are  fine  until  one  wishes  to  compose  new  actions  to  existing  ones.  At  this  point,  since  the  notion  of  a  slot  is 
a  weakened  and  limited  version  of  the  uotion  of  a  function,  to  define  the  composition  of  slot  executions,  the 
user  must  escape  to  LISP  where  she  can  use  the  full  notion  of  functional  composition  and  sequencing. 

The  solution  to  this  problem,  as  I  suggest  in  IHaakGcj,  is  to  develop  a  programming  language  with  the 
self-descriptive  capacity  of  RLLs.  In  brief,  this  language  is  a  higher  order  language  similar  to  FP  [Bac78  with 
inferred  typing  of  functions  (much  as  in  ML  [Mil78)  and  the  addition  of  a  special  class  of  functions  —  called 
mutable  mappings  —  which  replace  the  functionality  of  slots  and  properties.  The  function  MAKE-MUTABLE 
constructs  a  mutable  function  which  is  simply  a  pairwise  mapping  of  objects.  The  function  MUTATOR  returns  a 
procedure  for  storing  mappings  for  the  mutable  function.  For  example,  the  following  uses  mutable  operations 
to  define  the  COLOR  function  and  set  the  color  of  a  few  objects. 


(define  color  (make-mutable)) 

COLOR 

(color  ‘apple) 

<  UNKNOW, \>  ;  Indicates  a  value  with  no  mapping. 

(define  def ine-color !  (mutator  color)) 

DEFIilE-COLOR 

(def ine-color!  'apple  ’red) 

<UNKNOWN>  ;  the  previous  return  value. 

(def ine-color!  'orange  'orange) 

<  UNKNOWN* 

(color  'apple) 

RED 

(color  'orange) 

ORA’.  ICE 

These  mutatable  functions  can  be  combined  with  higher  order  operators,  like  COMPOSE  or  RESTRICT-RAUGE. 
Here  we  defined  a  special  subset  of  colors  and  compose  this  with  a  class  of  fruits: 

(define  real-colors  (set-of  ’(red  green  blue  yellow  orange  pink))) 

REAL-COLORS  ;  The  value  of  this  is  a  type. 

(define  real-color  (restrict-range  color  real-colors)) 

REAL -COLOR 

(define  fruit  (make-mutable)) 

FRUIT 

(define  fruit-color  (compose  fruit  real-color)) 

FRUIT-COLOR 

So  defined,  we  ran  set  and  access  the  color  of  fruits  by  using  (lie  procedures  we  have  defined  and  then 
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associated  mutators. 

((mutator  fruit)  'apple-tree  ’apple) 

<  UNKNO  WN> 

(fruit-color  ’apple-tree) 

RED 

Knowledge  about  procedures  can  be  accessed  by  other  procedures,  in  particular,  DOMAIN  and  RADGE. 

(domain  color) 

#  [AlJYTHItIG] 

(range  color) 

# [ANYTHING] 

(range  real-color) 

#[0ne  of  RED  GREEN  BLUE  YELLOV.'  ORANGE  PINK] 

(range  fruit-color) 

#  [One  of  RED  GREEN  BLUE  YELLOV.'  ORANGE  PINK] 

By  defining  all  of  ones  representational  constructs  in  this  way,  the  expressive  power  of  our  representation 
language  is  nearly  equal  to  that  of  LISP-like  languages  while  still  giving  us  the  power  of  an  RLL. 

5.3  Why  RLL’s  Aren't  So  Bad 

In  the  previous  section,  an  argument  was  introduced  for  a  new  sort  of  representation  language  language, 
criticizing  fundamental  flaws  in  most  representation  language  languages  to  date.  An  important  point  to 
make  however,  is  that  the  criticism  applies  primarily  to  programs  which  must  learn  by  accquiring  new 
representations  and  definitions.  For  implementing  any  given  A1  program  —  capturing  a  given  domain’s 
expertise  —  an  RLL  provides  a  powerful  toolkit  for  building  a  specially  tailored  representation.  Only  when 
new  tools  must  be  built  do  traditional  RLLs  falter  or  fail. 

In  conclusion,  the  reasons  for  wanting  to  have  an  RLL  are  sustained;  self-debugging,  self-explanation, 
and  self-modification  are  greatly  enhanced  by  having  a  representation  of  the  representation  being  used. 
Unfortunately,  these  reasons  are  countervailed  as  the  expressive  demands  on  the  language  require  escape  to 
a  ‘real’  programming  language.  The  solution  —  it  then  seems  —  must  be  to  make  an  RLL  which  is  a  ‘real 
programming  language. 
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Chapter  A-l 

An  ARLO  ‘Explanation’ 


These  units  are  best  organised  by  the  My  File  Of  Definition  relation. 

A- 1.1  Units  defined  in  Arlo:  SOURCES;  BOOT 

These  units  are  best  organised  by  the  Makes  Sense  For  relation. 

A-l. 1.1  Units  with  a  Makes  Sense  For  slot  of  Any-Type 

The  unit  Defaulting  Slot  is  defined  in  the  knowledge  base  Core.  This  is  the  prototype  for  slots  which 
default  their  values. 

The  unit  Generic  Slot  is  defined  in  the  knowledge  base  Core.  This  is  a  prototypical  “generic”  slot 
which  looks  for  local  slot  definitions  on  each  unit. 

The  unit  Primitive  Slot  is  defined  in  the  knowledge  base  Core.  This  is  the  simplest  prototype  slot. 
The  unit  Prototype  is  defined  in  the  knowledge  base  Core.  This  is  a  unit’s  prototype. 

A-l. 1.2  Units  with  a  Makes  Sense  For  slot  of  Slot-Type 

These  units  all  have  PROTOTYPE  slots  of  Slot. 

These  units  are  best  organized  by  the  Data  Type  relation. 

Units  with  a  Data  Type  slot  of  Function-Type 

These  units  are  best  organized  by  the  To  Default  Value  relation. 

Units  with  a  To  Default  Value  slot  of  # ’DECACHE-FINDER 

To-Decache-Value  is  a  slot  which  accepts  values  of  type  Function  Type  and  makes  sense  for  units  of  type 
Slot  Type.  This  is  a  slot’s  function  for  invalidating  it’s  value  on  a  unit.  Its  value  defaults  by  the  function 
ARLO:DECAC'HE-FINDER,  which: 

This  finds  the  deaching  function  for  a  unit  by  looking  through  its  prototypes. 

Units  with  a  To  Default  Value  slot  of  #’DONT-DEFAULT-SLOT 
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To-D«fault-Value  is  a  slot  which  accepts  values  of  type  Function  Type  and  makes  sense  for  units  of  type 
Slot  Type.  This  is  the  function  for  computing  the  value  of  a  slot  at  need.  Its  value  defaults  by  the  function 
ARLO:DONT-DEFAULT-SLOT,  which: 

Signals  an  error  if  called  to  default  a  value. 

Units  with  a  To  Default  Value  slot  of  # ’FIND- VALUE 

Actual -Put -Value  is  a  slot  which  accepts  values  of  type  Function  Type  and  makes  sense  for  units  of  type 
Slot  Type.  This  is  a  slot’s  function  for  “physically”  depositing  its  value.  Its  value  defaults  by  the  function 
ARLO:FIND- VALUE,  which: 

Look  through  the  prototoypes  of  a  unit  for  a  particular  slot. 

To-Cache-Value  is  a  slot  which  accepts  values  of  type  Function  Type  and  makes  sense  for  units  of  type  Slot 
Type.  This  is  a  slot’s  function  for  caching  its  value.  Its  value  defaults  by  the  function  ARLO:FIND-  VALUE, 
which: 

Look  through  the  prototoypes  of  a  unit  for  a  particular  slot. 

To-Get -Value  is  a  slot  which  accepts  values  of  type  Function  Type  and  makes  sense  for  units  of  type  Slot 
Type.  This  is  a  slot’s  procedure  for  fetching  its  value.  Its  value  defaults  by  the  function  ARL0:F1ND- VALUE, 
which: 

Look  through  the  prototoypes  of  a  unit  for  a  particular  slot. 

To-Process-Slot  is  a  slot  which  accepts  values  of  type  Function  Type  and  makes  sense  for  units  of  type 
Slot  Type.  This  is  a  slot’s  function  for  transforming  its  description  into  “print-queue”  form.  Its  value  defaults 
by  the  function  ARLO:FIND- VALUE,  which: 

Look  through  the  prototoypes  of  a  unit  for  a  particular  slot. 

To-Put -Value  is  a  slot  which  accepts  values  of  type  Function  Type  and  makes  sense  for  units  of  type  Slot 
Type.  This  is  a  slot’s  procedure  for  storing  a  value.  Its  value  defaults  by  the  function  ARL0:F1ND- VALUE, 
which: 

Look  through  the  prototoypes  of  a  unit  for  a  particular  slot. 

To-Retract-Value  is  a  slot  which  accepts  values  of  type  Function  Type  and  makes  sense  for  units  of  type 
Slot  Type.  This  is  a  slots  procedure  for  removing  its  value.  Its  value  defaults  by  the  function  ARLO:FlND- 
VALUE,  which: 

Look  through  the  prototoypes  of  a  unit  for  a  particular  slot. 

Units  with  a  To  Default  Value  slot  of  #'TO-GENERATE-SLOT-DESCRIBER 

To-Describe-Value  is  a  slot  which  accepts  values  of  type  Function  Type  and  makes  sense  for  units  of  type 
Slot  Type  This  is  a  slot’s  function  for  describing  its  value.  Its  value  defaults  by  the  function  ARLO:TO- 
GENER  ATE-SLOT-DESC'RIBER,  which: 

Generates  a  function  for  describing  a  slut’s  value. 

Units  with  a  To  Default  Value  slot  of  #’TO-GENER  ATE-SLOT-PRINTEn 
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To-Print-Value  is  a  slot  which  accepts  values  of  type  Function  Type  and  makes  sense  for  units  of  type 
Slot  Type.  This  is  the  function  for  printing  the  value  of  this  kind  of  slot.  Its  value  defaults  by  the  function 
ARLO:TO-GT  NERATE-SLOT-PR INTER,  which. 

Gets  the  function  for  printing  a  slot’s  value. 

Units  with  a  To  Default  Value  slot  of  #’TO-GENERATE-SLOT-READER 
To-R«ad-Value  is  a  slot  which  accepts  values  of  type  Function  Type  and  makes  sense  for  units  of  type 
Slot  Type.  This  is  a  slot’s  function  for  reading  in  its  value.  Its  value  defaults  by  the  function  ARLO:TO- 
GENERATE-SLOT-READER,  which. 

Gets  the  function  for  reading  in  a  slot’s  value. 

Units  with  a  To  Default  Value  slot  of  #’TO-GENERATE-TO-VERIFY-TYPE 

To-Verif y-Type  is  a  slot  which  accepts  values  of  type  Function  Type  and  makes  sense  for  units  of  type 
Slot  Type.  This  is  the  function  which  verifies  the  suitability  of  a  slot’s  attachment.  Its  value  defaults  by  the 
function  ARLO:TO-GENERATE-TO-VERIFY-TYPE,  which: 

Compute  a  slot’s  type  checker  with  the  Type-Checker  coder. 

Units  not  classifiable  by  To-Default -Value 

Actual  -Get-Value  is  a  slot  which  accepts  values  of  type  Function  Type  and  makes  sense  for  units  of  type 
Slot  Type.  This  is  a  slot’s  function  for  “physically”  extracting  its  value. 

Units  with  a  Data  Type  slot  of  Slot-Type 

Shadow-Slot  is  a  slot  which  accepts  values  of  type  Slot  Type  and  makes  sense  for  units  of  type  Slot  Type. 
This  is  the  prototype  for  all  slots  which  shadow  other  slots. 

Units  with  a  Data  Type  slot  of  Type -Type 

Data-Type  is  a  slot  which  accepts  values  of  type  Type  Type  and  makes  sense  for  units  of  type  Slot  Type.  This 
is  a  slot’s  description  of  its  acceptable  values-  its  range.  Its  value  defaults  by  the  function  ARLO:DATA- 
TYPE-GENERATOR,  which: 

Looks  through  the  prototypes  of  a  slot  for  its  data- type 

Makes -Sense -For  is  a  slot  which  accepts  values  of  type  Type  Type  and  makes  sense  for  units  of  type  Slot 
Type.  This  describes  the  sorts  of  units  a  slot  may  attach  to-  its  domain.  Its  value  defaults  by  the  function 
ARLO:MAKES-SENSE-FOR-GENER  ATOR,  which: 

Looks  through  the  prototypes  of  a  slot  for  its  attachment  type. 

A-l.1.3  Units  with  a  Makes  Sense  For  slot  of  Unit-Type 
These  units  are  best  organized  by  the  Prototype  relation. 

Units  with  a  prototype  of  Generic  Slot 

The  unit  Typed  Slot  is  defined  in  the  knowledge  base  Core  This  is  the  prototype  for  slots  which  perform 
type  checking 

Units  with  a  prototype  of  Defaulting  Slot 
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Slot  is  a  slot  which  accepts  values  of  type  Any  Type  and  makes  sense  for  units  of  type  Unit  Type.  This  is 
the  prototype  for  slots  which  both  default  and  type  check  their  values. 

Units  with  a  prototype  of  Slot 

These  units  are  best  organized  by  the  Data  Type  relation. 

Units  with  a  Data  Type  slot  of  Any-Type 

My-File-Of -Definition  is  a  slot  which  accepts  values  of  type  Any  Type  and  makes  sense  for  units  of  type 
Unit  Type.  This  is  the  file  in  which  a  unit  was  defined.  Its  value  defaults  by  the  function  ARLO:GET-TlME, 
which: 

Gets  the  current  universal  time. 

My-Uaae  is  a  slot  which  accepts  values  of  type  Any  Type  and  makes  sense  for  units  of  type  Unit  Type. 
This  is  a  unit’s  name.  Its  value  defaults  by  the  function  ARLO:GENER  ATE-UNIT-NAME,  which: 
Generates  a  unit  name.  (Never  really  called?) 

Shadov -Slot-Slot  is  a  slot  which  accepts  values  of  type  Any  Type  and  makes  sense  for  units  of  type  Unit 
Type.  This  stores  the  slot  referring  to  ways  to  find  a  slot. 

Units  with  a  Data  Type  slot  of  Function-Type 

My -To -Describe -Self  is  a  slot  which  accepts  values  of  type  Function  Type  and  makes  sense  for  units  of 
type  Unit  Type.  This  is  a  unit’s  function  for  describing  itself.  Its  value  defaults  by  the  function  ARLO.  1‘NIT- 
DESCRIBER-GENER  ATOR,  which: 

Looks  through  the  prootypes  oj  a  unit  for  a  description  function. 

My-To-Prmt-Self  is  a  slot  which  accepts  values  of  type  Function  Type  and  makes  sense  for  units  of  type 
Unit  Type.  This  is  a  unit’s  function  for  printing  itself.  Its  value  defaults  by  the  function  ARLO:l’NIT- 
PR1NTER-GENERATOR,  which: 

Looks  through  the  prootypes  of  a  unit  for  a  printer  function. 

Units  with  a  Data  Type  slot  of  List-Type 

High-Level-Def  mition  is  a  slot  which  accepts  values  of  type  List  Type  and  makes  sense  for  units  of  type 
Unit  Type.  This  is  a  definition  for  some  function  in  a  high  level  language.  Its  value  defaults  by  the  function 
ARLO: ASK- USER- FOR -SLOT,  which: 

Asks  user  for  a  slot  on  a  window  that’s  big  enough. 

Units  with  a  Data  Type  slot  of  String-Type 

Description  is  a  slot  which  accepts  values  of  type  String  Type  and  makes  sense  for  units  of  type  Unit 
Type.  This  is  a  string  describing  what  this  unit  is.  Its  value  defaults  by  the  function  ARLO:DEFAl  LT- 
DESCRIPTION-GENER ATOR.  which: 

This  generates  a  description  excuse 

My-Creator  is  a  slot  w  hich  accepts  values  of  type  String  Typt  and  makes  sense  (or  units  of  type  Unit  Type. 
This  is  the  user  who  created  (actually,  compiled)  a  unit.  Its  value  defaults  by  the  function  ARLO  GET- 
HACKER,  which: 

Returns  the  full  norm  «/  the  current  user,  as  a  string 
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Units  with  a  Data  Type  slot  of  Tiae-Type 

My-Tiae-Of -Creation  is  a  slot  which  accepts  values  of  type  Time  Type  and  makes  sense  for  units  of  type 
Unit  Type.  This  is  the  time  when  a  unit  was  created  (as  “universal”  time)  Its  value  defaults  by  the  function 
ARLOGET-TIME.  which: 

Get s  the  current  universal  time. 

A-1.2  Units  defined  in  Arlo:  SOURCES;  CODERS 

These  units  are  best  organized  by  the  Data  Type  relation. 

A-1.2. 1  Units  with  a  Data  Type  slot  of  Any-Type 

These  units  all  have  PROTOTYPE  slots  of  Function-Descriptor. 

These  units  all  have  MAKES-SENSE-FOR  slots  of  I*ple»ented-Function-Type. 

Errors-Expected  is  a  slot  which  accepts  values  of  type  Any  Type  and  makes  sense  for  units  of  type 
Implemented  Function  Type.  A  descriptor  for  the  EXPECTING  coder. 

From-Unit  is  a  slot  which  accepts  values  of  type  Any  Type  and  makes  sense  for  units  of  type  Implemented 
Function  Type.  A  descriptor  for  the  INHERITS?  coder. 

Message-Spec  is  a  slot  which  accepts  values  of  type  Any  Type  and  makes  sense  for  units  of  type  Imple¬ 
mented  Function  Type.  A  descriptor  for  the  ASK-HACKER  coder. 

Method-Descriptions  is  a  slot  which  accepts  values  of  type  Any  Type  and  makes  sense  for  units  of  type 
Implemented  Function  Type.  The  ARLO  units  describing  each  coder.  Its  value  defaults  by  the  function 
ARLO:GENERATE-METHOD-DESC'RlPTIONS,  which: 

Generates  descriptions  for  each  method  in  a  try  and- try- again  function. 

Possible- Methods  is  a  slot  which  accepts  values  of  type  Any  Type  and  makes  sense  for  units  of  type 
Implemented  Function  Type.  A  descriptor  for  the  EXPECTING  coder. 

Slot -To- Inherit -Through  is  a  slot  which  accepts  values  of  type  Any  Type  and  makes  sense  for  units  of 
type  Implemented  Function  Type.  A  descriptor  for  the  INHERIT-THROUGH  coder. 

Slot-To-Search-Through  is  a  slot  which  accepts  values  of  type  Any  Type  and  makes  sense  for  units  of 
type  Implemented  Function  Type.  A  descriptor  for  the  INHERITS?  coder. 

Slots-To-Combine  is  a  slot  which  accepts  values  of  type  Any  Type  and  makes  sense  for  units  of  type 
Implemented  Function  Type.  A  descriptor  for  the  SLOT-COMPOSITION  coder. 

Test-Criterion  is  a  slot  which  accepts  values  of  type  Any  Type  and  makes  sense  for  units  of  type 
Implemented  Function  Type.  A  descriptor  for  the  TEST  coder. 

A-1.2. 2  Units  not  classifiable  by  Data-Type 

These  units  are  best  organized  by  the  Prototype  relation. 

Units  with  a  prototype  of  Coder 

ASK-HAC'KER  is  an  ARLO  coder.  This  generate.,  a  question  asking  function.  The  functions  it  generates 
are  specified  by  otie  parameter:  Message-Spec  .  It’s  body  is  generated  by  the  function  GENER ATE- ASK- 
HACKER 
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EXPECTING  is  an  ARLO  coder.  This  defines  a  try  and  try  again  function  which  expects  certain 
error#..  The  functions  it  generates  are  specified  by  two  parameters:  Errors -Expected  and  Possible-Methods 
It's  body  is  generated  by  the  function  GENER  ATE-EXPECTING 

INHER IT-THROUGH  is  an  ARLO  coder  This  defines  functions  which  search  for  values  along  some 
relation..  The  functions  it  generates  are  specified  by  one  parameter:  Slot-To-Inhent-Through  .  It’s  body  is 
generated  by  the  function  GENER ATE-INHERIT-THROUGH. 

INHERITS0  is  an  ARLO  coder.  This  implements  a  function  for  confirming  inheritance  along  some 
relation..  The  functions  it  generates  are  specified  by  two  parameters:  From-Unit  and  Slot-To-Search-Through. 
It’s  body  is  generated  by  the  function  GENER ATE-INHER ITS?. 

METHODS  is  an  ARLO  coder.  This  builds  a  try  and  try  again  function..  The  functions  it  generates 
are  specified  by  one  parameter:  Possible-Methods  .  It’s  body  is  generated  by  the  function  GENERATE- 
METHODS. 

SLOT-COMPOSITION  is  an  ARLO  coder.  This  generates  a  slot  composition  function.  The  functions 
it  generates  are  specified  by  one  parameter:  SlotB-To-Combine  .  It’s  body  is  generated  by  the  function 
GENERATE-SLOT-COMPOS1TION. 

TEST  is  an  ARLO  coder.  This  defines  a  complicated  conjunction  of  many  predicates..  The  func¬ 
tions  it  generates  are  specified  by  one  parameter:  Test-Criterion  .  It’s  body  is  generated  by  the  function 
GENERATE-TEST. 


Units  with  a  prototype  of  Hand  Coded  Function 

G El! ERATE -  1-lETH 0D  - DESCRIPTIONS  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (UNIT  IGNORE), 
and  is  documented  a#.  “Generates  descriptions  for  each  method  in  a  try-and-try-ngain  function.”. 


A-1.3  Units  defined  in  Arlo:  SOURCES;  CODING 


These  units  are  best  organized  by  the  Makes  Sense  For  relation. 

A-l.3.1  Units  with  a  Makes  Sense  For  slot  of  Coded-Function-Type 


Coded-By  is  a  slot  which  accepts  values  of  type  Coder  Type  and  makes  sense  for  units  of  type  Coded 
Function  Type.  This  i#  the  unit  describing  the  implementation  of  this  function.  Its  value  defaults  by  the 
function  A R  LO:DONT- DEFA l’LT-SLOT.  which: 


Signals  an  error  if  called  to  default  a  value. 

Internal-llame  is  a  slot  which  accepts  values  of  type  Symbol  Type  and  makes  sense  for  units  of  type 
Coded  Function  Type.  This  is  the  unit  describing  the  implementation  of  this  function.  Its  value  defaults  by 
the  function  AR  LO:GEN  ERATE- INTERN  \  1,-FU  NOTION-NAME,  which: 

This  consts  an  ugly  internal  function  name  for  a  description . 


A-1.3. 2  Units  with  a  Makes  Sense  For  slot  of  Coder-Type 


Coder-Slot  is  a  slot  which  accepts  values  of  type  Any  Typi  and  makes  sense  foi  units  of  type  Coder 
Tyjn  This  is  t  lie  |>l  "t  otype  for  all  pan  s  of  rodei  de-t  i  ipl  i,  .|»  - .  1 1  -  value  del  a  tilt .-  1>\  the  flint  I  ion  A  R  1.0:  A  SK- 
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USER-FOR-SLOT,  which: 

Asks  user  for  a  slot  on  a  window  that’s  big  enough. 

Description-Parameters  is  a  slot  which  accepts  values  of  type  List  Type  and  makes  sense  for  units  of 
type  Coder  Type.  These  are  the  specifications  from  which  the  function  is  generated. 

Documentor  is  a  slot  which  accepts  values  of  type  Function  Type  and  makes  sense  for  units  of  type  Coder 
Type.  This  is  the  function  which  documents  this  sort  of  function. 

Implementor  is  a  slot  which  accepts  values  of  type  Function  Type  and  makes  sense  for  units  of  type  C’oder 
Type.  This  is  the  function  which  codes  up  this  sort  of  function. 

’.lame -Generator  is  a  slot  which  accepts  values  of  type  Function  Type  and  makes  sense  for  units  of  type 
Coder  Type.  This  is  the  function  which  names  this  sort  of  function.  Its  value  defaults  by  the  function 
ARLO.TO-DEFAULT-NAME-GENERATOR,  which: 

This  generates  a  function  which  generates  function  name  generators. 

A-l.3.3  Units  with  a  Makes  Sense  For  slot  of  @T[Function-Type] 

Function-Debugging- Info  is  a  slot  which  accepts  values  of  type  List  Type  and  makes  sense  for  units  of 
type  Function  Type.  This  is  random  debugging  information  for  a  function.  (Generated  by  the  compiler)  Its 
value  defaults  by  the  function  ARLO.TO-DEFAULT-FUNOTION-DEBUGGING-INFO,  which: 

This  finds  the  internal  debugging  information  for  a  function. 

Function-Max- Args  is  a  slot  which  accepts  values  of  type  Integer  Type  and  makes  sense  for  units  of  type 
Function  Type.  This  is  the  maximum  number  of  arguments  a  function  may  take.  Its  value  defaults  by  the 
function  ARLO:TO-DEFAULT-MAX-ARGS,  which: 

This  returns  the  maximnum  number  of  args  a  function  may  take. 

Function-Kin-Args  is  a  slot  which  accepts  values  of  type  Integer  Type  and  makes  sense  for  units  of  type 
Function  Type.  This  is  the  minimum  number  of  args  a  function  requires.  Its  value  defaults  by  the  function 
A RLO:TO- DEFAULT- MIN- ARGS,  which: 

This  returns  the  minimum  number  of  args  a  function  takes. 

Ilacros-Used  is  a  slot  which  accepts  values  of  type  List  Type  and  makes  sense  for  units  of  type  Function 
Type.  This  is  the  macros  used  in  defining  a  function.  Its  value  defaults  by  the  function  ARLO:TO-DEFAULT- 
MAC'ROS-USED,  which: 

This  determines  what  rnacros  were  expanded  for  a  given  function. 

Magic-Argument-Descriptor  is  a  slot  which  accepts  values  of  type  Integer  Type  and  makes  sense  for  units 
of  type  Function  Type.  This  is  a  magic  number  describing  a  functions  arguments  (generated  by  the  compiler) 
Its  value  defaults  by  the  function  ARLO:TO-DEFAULT-MAGIO-ARGUM ENT- DESCRIPTOR,  which: 

This  returns  a  magical  argument  descriptor  for  a  function. 

A-l.3.4  Units  with  a  Makes  Sense  For  slot  of  Implemented-Function-Type 
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Units  with  a  prototype  of  Slot 

Function-Descriptor  is  a  slot  which  accepts  values  of  type  Any  Type  and  makes  sense  for  units  of  type 
i  Implemented  Function  Type  This  the  prototype  for  attributes  describing  functions. 

I  Units  with  a  prototype  of  Function  Descriptor 

These  units  are  best  organized  by  the  Data  Type  relation. 

Units  with  a  Data  Type  slot  of  Liep-Function-Type 

Functional -Value  is  a  slot  which  accepts  values  of  type  Lisp  Function  Type  and  makes  sense  for  units  of 
|  type  Implemented  Function  Type.  This  is  a  version  of  the  function  acceptable  to  APPLY.  Its  value  defaults 

I  by  the  function  ARLO:TO-DEFAULT-FUNCTIONAL- VALUE,  which: 

Gets  the  functional  value  -  compiled  or  interpreted  -  of  a  function. 

\  Units  with  a  Data  Type  slot  of  Liat-Type 

Arglist  is  a  slot  which  accepts  values  of  type  List  Type  and  makes  sense  for  units  of  type  Implemented 
Function  Type.  This  is  the  argument  list  for  a  function.  Its  value  defaults  by  the  function  ARLO:TO- 
DEFAULT- ARGLIST,  which. 

Defaults  the  arglist  of  a  function. 

Lambda -Body  is  a  slot  which  accepts  values  of  type  List  Type  and  makes  sense  for  units  of  type  Implemented 
Function  Type.  This  is  the  body  of  the  function.  Its  value  defaults  by  the  function  ARLO:TO-DEFAULT- 
LAMBDA-BODY,  which: 

Finds  or  generates  a  lambda  body  for  a  function. 

Lambda-Definition  is  a  slot  which  accepts  values  of  type  List  Type  and  makes  sense  for  units  of  type 
Implemented  Function  Type.  This  is  the  lambda  definition  of  a  function.  Its  value  defaults  by  the  function 
ARLO.TO-DEFAULT-LAMBDA-DEFINITION,  which: 

This  tries  to  compute  a  lambda  definition  for  a  slot. 

Units  with  a  Data  Type  slot  of  String-Type 

Documentation  is  a  slot  which  accepts  values  of  type  String  Type  and  makes  sense  for  units  of  type 
Implemented  Function  Type.  This  is  the  documentation  for  a  function.  Its  value  defaults  by  the  function 
ARLO:TO-DEFAULT-DOCUMENTATION,  which: 

Finds  the  documentation  for  a  function. 

Units  with  a  Data  Type  slot  of  Subr-Type 

Compiled-Definition  is  a  slot  which  accepts  values  of  type  Subr  Type  and  makes  sense  for  units  of  type 
Implemented  Function  Type.  This  is  the  compiled  definition  of  a  function.  Its  value  defaults  by  the  function 
ARLO:TO-DEFAULT-OOMP1LED-DEF1NITION,  Which: 

Compiles  the  definition  of  a  function. 

Units  with  a  Data  Type  slot  of  Valid-Function-liame-Type 

Function-name  is  a  slot  which  accepts  values  of  type  Valid  Function  Name  Type  and  makes  sense  for 
units  of  type  Implemented  Function  Type.  This  is  the  function  spec  for  the  function  described  by  a  unit.  Its 
value  defaults  by  the  function  ARLO:TO-DEFAULT-FUN('T10N-,NAME.  which: 

Computes  a  function  name  by  looking  on  a  coder  slot. 
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A-l.3.5  Units  not  classifiable  by  Makes-Sense-For 

The  unit  Coder  is  defined  in  the  knowledge  base  Core.  This  is  the  prototype  for  all  ARLO’s  automatic 
coders. 

The  unit  Hand  Coded  Function  is  defined  in  the  knowledge  base  Core.  This  is  the  prototype  for 
functions  defined  by  DEFINE. 

The  unit  Implemented  Function  is  defined  in  the  knowledge  base  Core.  This  is  the  prototype  for 
implemented  LISP  function  descriptions. 

A-1.4  Units  defined  in  Arlo:  SOURCES;  LISP 

These  units  all  have  PROTOTYPE  slots  of  Hand-Coded-Function.  FIHD-VALUE  is  a  user  defined  lisp 
function  which  has  an  argument  list  of  (UNIT  SLOT),  and  is  documented  as:  ° Look  through  the  prototypes 
of  a  unit  for  a  particular  slot.”. 

GENERATE- INTERNAL- FUNCTI0I1-HAME  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (UNIT 
IGNORE),  and  is  documented  as:  “This  conses  an  ugly  internal  function  name  for  a  description.”. 

MAKES- SENSE-FOR-GENERATOR  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (UNIT  SLOT), 
and  is  documented  as:  “Looks  through  the  prototypes  of  a  slot  for  its  attachment  type.”. 

TO-DEFAULT-COMPILED-DEFINITION  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (UNIT 
IGNORE),  and  is  documented  as:  “Compiles  the  definition  of  a  function.”. 

TO-DEFAULT-DOCUMENTATION  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (UNIT  IGNORE), 
and  is  documented  as:  “Finds  the  documentation  for  a  function.’’. 

TO- DEFAULT -FU1ICTI01!- 11 AME  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (UNIT  IGNORE), 
and  is  documented  as:  “Computes  a  function  name  by  looking  on  a  coder  slot.”. 

TO-  DEF  AULT  -  FUN  CT 1 0 11 AL  -  VALUE  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (UNIT  IG¬ 
NORE),  and  is  documented  as:  “Gets  the  functional  value  -  compiled  or  interpreted  -  of  a  function.”. 

TO-DEFAULT  - LAMBDA- BODY  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (UNIT  IGNORE), 
and  is  documented  as:  “Finds  or  generates  a  lambda  body  for  a  function.” 

TO-DEFAULT-LAMBDA-DEFI1IITIOU  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (UNIT 
IGNORE),  and  is  documented  as:  “This  tries  to  compute  a  lambda  definition  for  a  slot.”. 

TO-GEUERATE-TO-VERIFY-TYPE  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (SLOT  IG¬ 
NORE),  and  is  documented  as:  “Comjiute  a  slot’s  type  checker  with  the  Type-  Checker  coder.”. 

UllTT-PRIUTER-GElIERATOR  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (UNIT  SLOT),  and 
is  documented  as:  “Looks  through  the  prootypes  of  a  unit  for  a  printer  function.”. 

A-1.5  Units  defined  in  Arlo:  SOURCES;  TYPES 

These  units  are  best  organized  by  the  Prototype  relation. 

A-l.5.1  Units  without  any  prototype. 

The  unit  Type  is  defined  in  the  knowledge  base  Core.  This  is  the  prototype  for  all  types.  It  accepts 
anything. 
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A-l.5.2  Units  with  a  prototype  of  Coder 

TYPE-CHECKER  is  an  ARLO  coder.  Generates  a  type  checking  function  for  a  slot..  The  func¬ 
tions  it  generates  are  specified  by  one  parameter:  Relevant-Slot  .  It’s  body  is  generated  by  the  function 
GENERATE-TYPE-CHECKER. 

A-l.5.3  Units  with  a  prototype  of  Function  Descriptor 

Relevant-Slot  is  a  slot  which  accepts  values  of  type  Any  Type  and  makes  sense  for  units  of  type  Imple¬ 
mented  Function  Type.  A  descriptor  for  the  TYPE-CHECKER  coder. 

A-l.5.4  Units  with  a  prototype  of  Hand  Coded  Function 

T0-GE1IERATE-SL0T-DESCRIBER  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (UNIT  IG¬ 
NORE),  and  is  documented  as:  “ Generates  a  junction  Jot  describing  a  slot's  value.”. 

TO-GE!IERATE-SLOT -PRINTER  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (UNIT  IGNORE), 
and  is  documented  as:  “Gets  the  function  for  printing  a  slot’s  value.”. 

T0-GEI!ERATE-SL0T-READ£R  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (UNIT  IGNORE), 
and  is  documented  as:  “Gets  the  function  for  reading  in  a  slot’s  value.”. 

TO-GEIiERATE-TYPE-CHECKER  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (UNIT  IGNORE), 
and  is  documented  as:  “ Generates  the  type  checking  function  for  a  type.”. 

A-l.5.5  Units  with  a  prototype  of  Slot 


These  units  are  best  organized  by  the  Data  Type  relation.  | 

Units  with  a  Data  Type  slot  of  Function-Type 

Function-To-Deacribe  is  a  slot  which  accepts  values  of  type  Function  Type  and  makes  sense  for  units  of  type 
Type  Type.  This  is  the  function  for  describing  a  value  of  a  particular  type.  Its  value  defaults  by  the  function  i 

1NHER1T-THR0UGH-GENERAL1ZAT10N,  which:  ! 

Searches  through  the  CORE-GENERALIZATION  slots  of  a  unit  for  a  value.  [ 

Function-To-Prmt  is  a  slot  which  accepts  values  of  type  Function  Type  and  makes  sense  for  units  of  type 
Type  Type.  This  is  the  function  for  printing  a  value  of  a  particular  type.  Its  value  defaults  by  the  function 
IN  HER  IT-TH  ROUGH-GENERALIZATION,  which:  ' 

Searches  through  the  CORE-GENERALIZATION  slots  of  a  unit  for  a  value.  ) 

Function-To-Read  is  a  slot  which  accepts  values  of  type  Function  Type  and  makes  sense  for  units  of  type 
Type  Type.  This  is  the  function  for  reading  a  value  of  a  particular  type.  Its  value  defaults  by  the  function 
IN  HER  IT-TH  ROUGH-GENER  ALIZATION,  which. 

Searches  through  the  C^ORE  GENER ALIZATION  slots  of  a  unit  for  a  value. 

Specification  is  a  slot  which  accepts  values  of  type  Function  Type  and  makes  sense  for  units  of  type  Type  ] 

Type.  This  is  the  function  which  specializes  this  type.  Its  value  defaults  by  the  function  ARLO:QUESTION-  J 

2.  which:  < 

Ask  the  user  a  question  by:  Jj 
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( FORMAT  QUERY- IO 

“  &Wkat  predicate  specifies  a  from  a?” 

UNIT 

(GET-  VALUE  UNIT  ^GENERALIZATION 

Type-Checking-Function  is  a  slot  which  accepts  values  of  type  Function  Type  and  makes  sense  for  units  of 
type  Type  Type.  This  is  the  predicate  for  a  type.  Its  value  defaults  by  the  function  ARLO.'TO-GENERATE- 
TYPE-CHECKER,  which: 

Generates  the  type  checking  function  for  a  type. 

Units  with  a  Data  Type  slot  of  Type-Type 

Generalization  is  a  slot  which  accepts  values  of  type  Type  Type  and  makes  sense  for  units  of  type  Type  Type. 
This  is  the  type  upon  which  a  given  type  is  built.  Its  value  defaults  by  the  function  ARLO:QUESTION-l, 
which: 

Ask  the  user  a  question  by: 

(FORMAT  QUERY-10  “  &  What  is  a  a  specialization  of'  ”  UNIT) 

lly-Specif ic-Type  is  a  slot,  which  accepts  values  of  type  Type  Type  and  makes  sense  for  units  of  type 
Unit  Type.  This  is  how  to  tell  if  a  unit  inherits  from  this  unit. 

A-l.5.6  Units  with  a  prototype  of  Type 

These  units  are  best  organized  by  the  Generalization  relation. 

Types  without  any  generalizations. 

Any-Type  specifies  the  class  of  LISP  objects  which  satisfy  the  predicate  ANYTHINGP  (documented  as  “A 
unparticular  type  predicate.”).  This  is  the  top  of  the  type  hierarchy. 

Types  which  are  specializations  of  Any  Type 

Function-Type  specifies  a  class  of  lisp  objects  which  are  classified  by  Any-Type  and  which  additionally  satisfy 
the  predicate  C'ALLABLEP  (documented  as  “ Determines  if  an  object  is  either  a  function  or  a  function- 
describing  unit”).  This  is  a  type  satisifed  by  any  callable  object  (including  function  descriptions). 

Integer-Type  specifies  a  class  of  lisp  objects  which  are  classified  by  Any-Type  and  which  additionally 
satisfy  the  predicate  FIXP.  This  is  a  type  requiring  a  LISP  integer,  (a  fixnum  or  a  bignum) 

List-Type  specif!  ’s  a  class  of  lisp  objects  which  are  classified  by  Any-Type  and  which  additionally  satisfy 
the  predicate  LIST-OR-NIL-P  (d  ocumented  ns  “ A  predicate  which  accepts  conses  and  NIL”).  This  is  a  type 
satisfied  by  any  list  (including  NIL). 

Pathname-Type  specifies  a  class  of  lisp  objects  which  are  classified  by  Any-Type  and  which  additionally 
satisfy  the  predicate  PATHNAMEP.  This  is  a  type  which  is  satisfied  by  any  pathname 

String-Type  specifies  a  class  of  lisp  objects  which  are  classified  by  Any-Type  and  which  additionally  sat  isfy 
the  predicate  STR1NGP.  This  is  a  type  satisifed  by  any  string. 

Symbol-Type  specifies  a  class  of  lisp  objects  which  are  classified  by  Any-Type  and  which  additionally  satisfy 
the  predicate  SYMBOLP.  This  is  a  type  .-atisified  by  any  LISP  symbol. 
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Unit -Type  specifies  a  class  of  lisp  objects  which  are  classified  by  Any-Type  and  which  additionally  satisfy 
the  predicate  UNITP  (documented  as  “ Function  determining  if  something  is  a  unit-  used  by  TYPEP").  This 
is  a  type  describing  any  ARLO  unit. 

i  Types  which  are  specializations  of  Function  Type 

Implemented-Function-Type  specifies  a  chiss  of  lisp  objects  which  .are  classified  by  Function-Type  and  which 
additionally  satisfy  the  predicate  IMPLEMENTED-FUNCTION?.  This  is  a  type  satisifed  by  any  lisp  func¬ 
tion. 

I 

I  Lisp-Function-Type  specifies  a  class  of  lisp  objects  which  are  classified  by  Function-Type  and  which 

additionally  satisfy  the  predicate  FUNC'TIONP.  This  is  a  type  satisifed  by  any  lisp  function. 

Subr-Type  specifies  a  class  of  lisp  objects  which  are  classified  by  Function-Type  and  which  additionally 
I  satisfy  the  predicate  SUBRP.  This  is  a  type  satisfied  by  any  LISP  callable  object  (i.e.  APPLIcable) 

Valid-Function-!;ame-Type  specifies  a  class  of  lisp  objects  which  are  classified  by  Function-Type  and 
which  additionally  satisfy  the  predicate  VALIDATE-FUNOTION-SPEO.  This  is  a  type  satisifed  by  any  lisp 
function  spec. 

Types  which  are  specializations  of  Implemented  Function  Type 

Coded-Function-Type  specifies  a  class  of  lisp  objects  which  are  classified  by  Implemented-Function-Type  and 
which  additionally  satisfy  the  predicate  PROTOTYPE-OF-CODED-FUNC'TION?  (documented  as  “ Checks 
to  set  if  a  unit  inherits  from  C'ORE:CODED  FUNCTION  via  CORE:PROTOTYPE" ) .  This  is  a  type 
satisifed  by  any  lisp  function. 

Types  which  are  specializations  of  Integer  Type 

Time-Type  specifies  a  class  of  lisp  objects  which  are  classified  by  Integer-Type  and  which  additionally  satisfy 
the  predicate  FIXP.  This  is  a  type  requiring  an  integer  indicating  seconds  past  the  turn  of  the  century. 

Types  which  are  specializations  of  Unit  Type 

Coder-Type  specifies  a  class  of  lisp  objects  which  are  classified  by  Unit-Type  and  which  additionally  satisfy 
the  predicate  CODER?.  This  is  a  type  describing  any  ARLO  slot. 

Slot -Type  specifies  a  class  of  lisp  objects  which  are  classified  by  Unit -Type  and  which  additionally  satisfy 
the  predicate  SLOT?  (documented  as  ” Determines  if  a  unit  is  a  slot  fi.e.  has  PRIMITIVE-SLOT  as  a 
prototype J”).  This  is  a  type  describing  any  ARLO  slot. 

Type-Type  specifies  a  class  of  lisp  objects  which  are  classified  by  Unit-Type  and  which  additionally  satisfy 
the  predicate  IS-  IT-  A-TYPE-P  (documented  as  “Determines  if  something  is  a  unit  inheriting  from  TYPE.") 
This  is  a  type  which  is  satisified  by  any  type  describing  ARLO  unit. 

A-1.6  Units  defined  in  Arlo:  SOURCES;  WHISTLES 

(PROPERTY  ARLO-UIIIT  !;A!  !ED-STRUCTURE- INVOKE)  is  a  user  defined  lisp  function  which  has  an  argument  list 
of  (OP  UNIT  A- REST  M  ISC- ARCS).  and  is  documented  as:  “ Data  uirtcltd  pretty  printing  and  describing 
for  units.". 
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Chapter  A-2 

An  Explanation  ‘Explanation’ 


These  units  are  best  organized  by  the  My  File  Of  Definition  relation. 

A-2.1  Units  defined  in  Arlo:  AI;  DOCUMENT 

These  units  are  best  organized  by  the  Prototype  relation. 

A-2. 1.1  Units  with  a  prototype  of  Explanation  Slot 

Positional- Assumptions  is  a  slot  which  accepts  values  of  type  Any  Type  and  makes  sense  for  units  of 
type  Explanation  Type.  These  are  The  slots  distinguished  by  this  explanations  superiors.  Its  value  defaults 
by  the  function  ARLO:TO-DEFAULT-POSIT10NAL-ASSUMPTIONS,  which: 

-  Adds  a  units  superiors  primary  division  to  its  positional  assumptions. 

Scribe-Documentor  is  a  slot  which  accepts  values  of  type  Function  Type  and  makes  sense  for  units  of 
type  Explanation  Type.  This  is  the  function  SCRIBE  documentation  fo  an  explanation.  Its  value  defaults 
by  the  function  ARLO:FIND- VALUE,  which: 

Look  through  the  prototoypes  of  a  unit  for  a  particular  slot. 

Scribe-Explanation-Title  is  a  slot  which  accepts  values  of  type  Any  Type  and  makes  sense  for  units  of 
type  Explanation  Type.  This  is  the  section  title  SCRIBE  should  use  for  this  explanation.  Its  value  defaults 
by  the  function  ARLO:GENERATE-SCRIBE- EXPLANATION-TITLE,  which: 

Attempts  to  generate  an  appropriate  scribe-style  heading  for  a  section. 

A-2.1  2  Units  with  a  prototype  of  Hand  Coded  Function 

DOCUMENT-FILE  is  a  user  defined  lisp  function  which  lias  an  argument  list  of  (PATHNAME  KB  TITLE), 
and  is  documented  as:  ’‘Documents  all  the  units  in  a  given  KB  coming  from  a  given  file.”. 

DOIIT-DEFAULT-SLOT  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (UNIT  SLOT),  and  is 
documented  as:  “ Signals  an  error  if  called  to  d,  fault  a  value.". 
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EXPLANATION -PRECEDENCE  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (EXPLANATION  1 
EXPLANAT10N2).  and  is  documented  as:  “ Establishes  an  order  on  a  hierarchy  oj  explanations.”. 

GEHERATE-SCRIBE-DOCUMENTATIOH-FOR-COMPL  EX- EXPLANATION  is  a  user  defined  lisp  function  which  has  an 
argument  list  of  (EXPLANATION  STREAM),  and  is  documented  as:  “Produces  scribe  documentation  f or 
an  explanation  of  a  set  of  units.”. 

GENERATE -SCRIBE -DOCUMENTATION- FOR- UNIT- EXPLANATION  is  a  user  defined  lisp  function  which  has  an  argu¬ 
ment  list  of  (EXPLANATION  STREAM),  and  is  documented  as:  “ Documents  a  unit  by  looking  for  a  scribe 
documentor  on  its  prototypes.”. 

GEI1ERATE-SCRIBE-EXPLANATI0!) -TITLE  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (EX¬ 
PLANATION  IGNORE),  and  is  documented  as:  “ Attempts  to  generate  an  appropriate  scribe-style  heading 
for  a  section.  ” . 

INHERITING?  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (SUPER  UNIT  BY-RELATION), 
and  is  documented  as:  “Determines  if  some  unit  inherits  another  by  some  relation.”. 

PRIllT-UNIT-FOR-SCRIBE  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (UNIT  STREAM), 
and  is  documented  as:  “Prints  a  unit  for  SCRIBE,  being  cute  about  knowledge  bases.”. 

RUN-SCRIBE-DOCU  MENiTOR  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (ON-EXPLANATION 
TO-BUFFER),  and  is  documented  as:  “Runs  the  documentor  on  some  explanation.”. 

SAY- SLOT -VALUE  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (UNIT  SLOT  STREAM), 
and  is  documented  as:  “Produces  a  psuedo-english  description  of  some  slot  value.". 

SCRIBE-ALPHABETIZE- EXPLANATIONS  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (EXPLA¬ 
NATIONS),  and  is  documented  as:  “Sorts  a  set  of  explanations  alphabetically  by  SCRIBE-EXPLANATION- 
TITLE”. 

SCRIBE-DOCUMENT-EXPLANATION  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (EXPLANA¬ 
TION  TO-STREAM),  and  is  documented  as:  “Generates  scribe  documentation  for  an  explanation.”. 

SCRIBE-DOCUMENT- PERSON -EXPLANATION  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (EX¬ 
PLANATION  STREAM),  and  is  documented  as:  “Produces  SCRIBE  documentation  for  a  person  descrip¬ 
tion.”. 

SCRIBE-DQCUi  ENT -RANDOM-COMPLEX -EXPLANATION  is  a  user  defined  lisp  function  which  has  an  argument  list 
of  (EXPLANATION  STREAM),  and  is  documented  as:  “ Documents  an  indistinctive  collection  of  units  ”. 

SCRIBE-D0CU1ENT0R- FOR- CODED -FUNCTIONS  is  a  user  defined  lisp  function  which  has  an  argument  list  of 
(EXPLANATION  STREAM),  and  is  documented  as:  “Produces  SCRIBE  documentation  for  an  automati¬ 
cally  coded  function.”. 

SCRIBE-DOCUIENTOR-FOR-CODERS  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (EXPLA¬ 
NATION  STREAM),  and  is  documented  as:  “Produces  SCRIBE  documentation  for  an  ARLO  coder.”. 

SCRI BE-D0CUME1IT0R- FOR -RANDOM-UN  IT- EXPLANATIONS  is  a  user  defined  lisp  funct  ion  which  has  an  argument 
list  of  (EXPLANATION  STREAM),  and  is  documented  as:  “Generates  a  scribe  explanation  for  a  unit 
explanation.  ”. 

SCRIBE-DOCU1ENTOR-FOR- SLOT- EXPLANATIONS  is  a  user  defined  lisp  function  which  has  an  argument  list  of 
(EXPLANATION  STREAM),  and  is  documented  a*:  “Generates  a  scribe  explanation  for  some  slot.”. 
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SCRIBE-DOCUMEHTOR-FOR-TYPE-EXPLAHATIOHS  is  a  user  defined  lisp  function  which  has  an  argument  list  of 
(EXPLANATION  STREAM),  and  is  documented  as:  “ Generates  a  scribe  explanation  for  some  slot.”. 

SCRIBE-DOCUMEKTOR-FOR-USER-FUIICTIOHS  is  a  user  defined  lisp  function  which  has  an  argument  list  of 
(EXPLANATION  STREAM),  and  is  documented  as:  “ Produces  SCRIBE  documentation  for  an  explanation 
of  a  user  function. 

SECTIOHIZE-BY-HIERARCHICAL-SLOT  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (EXPLA¬ 
NATION  STREAM),  and  is  documented  as:  “ Documents  a  collection  of  units  organized  by  a  hierarchical 
relation.  ”. 

SECTIOUIZE-FILE-OF-DEFIHITIOH-SLOT  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (EX¬ 
PLANATION  STREAM),  and  is  documented  as:  “Sets  sectionization  determined  by  file  of  definition.” . 

SECTIOllIZE-GEHERALIZATiail-SLOT  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (EXPLA¬ 
NATION  STREAM),  and  is  documented  as:  “Sectiomzes  based  on  the  GENERALIZATION  slot.”. 

SECTI01IIZE-PR0T0TYPE-SL0T  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (EXPLANA¬ 
TION  STREAM),  and  is  documented  as:  “ Sectiomzes  based  on  the  PROTOTYPE  slot.”. 

SECTIOHIZE-SUPERVISOR-SLOT  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (EXPLANA¬ 
TION  STREAM),  and  is  documented  as:  “Sectiomzes  based  on  the  INQUIR :SVPERV1S0R  slot.”. 

TO  -  DEFAULT- l-IY- TO-SCRIBE- DOCUMENT -SELF  is  a  user  defined  lisp  function  which  has  an  argument  list  of 
(UNIT  SLOT),  and  is  documented  as:  “ Looks  on  ones  prototypes  for  a  function  and  otherwise  returns  a 
default.”. 

TO- DEFAULT- P0SITI01IAL-ASSUMPTI OHS  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (EX¬ 
PLANATION  IGNORE),  and  is  documented  as:  “Adds  a  units  superiors  primary  division  to  its  positional 
assumptions. 

TO-DEFAULT-TO-SECTIOUIZE-BY  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (UNIT  SLOT), 
and  is  documented  as:  “Looks  on  ones  prototypes  for  a  function  and  otherwise  returns  a  default.  ”. 

A-2.1.3  Units  with  a  prototype  of  Slot 


My-To-Scribe-Document-Self  is  a  slot  which  accepts  values  of  type  Function  Type  and  makes  sense  for 
units  of  type  Unit  Type.  This  is  the  function  for  writing  SCRIBE  documentation  for  a  unit.  Its  value  defaults 
by  the  function  ARLO.TO-DEFAULT-MY-TO-SCRIBE-DOCUMENT-SELF,  which: 

Looks  on  ones  prototypes  for  a  function  and  otherwise  returns  a  default. 

To-Sectionize-By  is  a  slot  which  accepts  values  of  type  Function  Type  and  makes  sense  for  units  of  type 
Slot  Type.  This  is  the  function  for  sectionizing  a  description  focussed  on  this  slot.  Its  value  defaults  by  the 
function  ARLO:TO-DEFAULT- TO-SECTIONIZE-BY,  which: 

Looks  on  ones  prototypes  for  a  function  and  otherwise  returns  a  default. 

To-Speak-Value  is  a  slot  which  accepts  values  of  type  Function  Type  and  makes  sense  for  units  of  type 
Slot  Type.  This  describes  how  to  say  this  slot  in  English  (sort  of). 


A-2.2  Units  defined  in  Arlo:  AI:  EXPLAIN 


;se  units  are  best  organized  by  the  Prototype  relation. 
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A-2.2.1  Units  without  any  prototype.  ] 

The  unit  Explanation  is  defined  in  the  knowledge  base  Explain.  This  is  the  prototypical  explanation. 

A-2.2.2  Units  with  a  prototype  of  Explanation  Slot 

Explanation-Kb  is  a  slot  which  accepts  values  of  type  Any  Type  and  makes  sense  for  units  of  type 
Explanation  Type.  This  is  the  knowledge  base  in  which  this  explanation  is  consed  up.  Its  value  defaults  by  | 

the  function  ARLO:GET-ORIGINAL-KB,  which: 

Extracts  the  knowledge  base  a  unit  was  originally  in.  ' 

Explanation-Title  is  a  slot  which  accepts  values  of  type  String  Type  and  makes  sense  for  units  of  type 
Explanation  Type.  This  is  a  string  describing  this  explanation. 

Relevant-Slots  is  a  slot  which  accepts  values  of  type  Any  Type  and  makes  sense  for  units  of  type  , 

Explanation  Type.  This  is  a  list  of  the  slots  relevant  to  this  explanation.  Its  value  defaults  by  the  function 
INHERIT-THR0UGH-SUPER-EXPLANAT10N,  which: 

Searches  through  the  CORE:EXPLAIN:SVPER-EXPLANATION  slots  of  a  unit  for  a  value. 

Super-Explanation  is  a  slot  which  accepts  values  of  type  Any  Type  and  makes  sense  for  units  of  type 
Explanation  Type.  This  is  the  explanation  this  explanation  is  a  component  of. 

A-2.2.3  Units  with  a  prototype  of  Explanation 

The  unit  Unit  Explanation  is  defined  in  the  knowledge  base  Explain.  This  is  the  prototypical  expla¬ 
nation  of  an  individual  unit. 

The  unit  Unit  Set  Explanation  is  defined  in  the  knowledge  base  Explain.  This  is  the  prototypical 
explanation  of  a  set  of  units. 

A-2.2.4  Units  with  a  prototype  of  Hand  Coded  Function 

COMPUTE-CHUNK -SIZE  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (PARTITION),  and  is 
documented  as:  “ Computes  the  average  size  of  classified  chunks  in  this  partition.’’. 

COIl  STRUCT -EXPLANATION  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (TITLE  SYMBOLIC- 
DIVISION  IN-EXPLANATION  UNITS  STRUCTURE),  and  is  documented  as:  “ Constructs  an  explanation 
for  a  set  of  units.”. 

EXTEND-PARTITION  is  a  user  defined  lisp  function  which  lias  an  argument  list  of  (PARTITION  ELEMENT 
GROUP),  and  is  documented  as:  “This  adds  an  element  and  i Is  associated  group  -  to  a  partition.”. 

EXTRACT-  S 1 I IPLEST  -  PARTITION  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (PARTITIONS), 
and  is  documented  as:  “ Selects  the  partition  unth  the  largest  ‘chunks’  from  a  list  of  partitions.”. 

GENERATE-EXCUSES  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (EXPLANATION),  and 
is  documented  as:  “Generates  an  explanation  for  the  ‘misfits’  of  an  explanation.”. 

GENERATE-SET-PARTITIONS  is  a  user  defined  lisp  function  which  has  an  argument,  list  of  (FOR-EXPLAN  ATION), 
and  is  documented  as:  “Computes  or  reduces  ( from  its  supi  r- explanation)  the  partitions  for  an  explanation.  ”. 

GENERATE- SUB- EXPLANATIONS  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (EXPLANA¬ 
TION),  and  is  documented  as:  “Generates  sub  explanations  from  the  partition  of  'in  explanation . 
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GENERATE-UUIT-EXPLAIIATIOH  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (UNIT  SUPER¬ 
EXPLANATION),  and  is  documented  as:  “This  generates  an  explanation  object  for  a  particular  unit.". 

GET-ORIGI!!AL-KB  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (UNIT  IGNORE),  and  is 
documented  as:  “ Extracts  the  knowledge  base  a  unit  was  originally  in.’’ 

PARTITIOl.'-Ui'ITS  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (UNITS  BY-SLOT),  and 
is  documented  as:  “ This  takes  some  units  and  returns  the  partition  dt  jilted  over  them  by  some  slot.”. 

REDUCE-PARTITIOli  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (PARTITION  OVER- 
L  NITS),  and  is  documented  as:  “This  takes  the  subset  oj  a  partition  determined  by  some  set  of  units.’’. 

REDUCE-PARTITIOH-SET  is  a  user  defined  lisp  function  which  lias  an  argument  list  of  (PARTITION-SET 
OVER-UNITS  OVER-SLOTS),  and  is  documented  as:  “This  takes  a  set  of  partitions  and  reduces  each  one.”. 

T0-DEFAULT-SET-PARTITI011S  is  a  user  defined  lisp  function  which  lias  an  argument  list  of  (FOR-EXPLAN  ATION 
IGNORE),  and  is  documented  as:  “Computes  or  reduces  (from  its  super- ezplanationj  the  partitions  for  an 
explanation.  ”. 

TO-DEFAULT-SUB-DIVISIOIIS  is  a  user  defined  lisp  function  which  has  an  argument  list  of  (EXPLANATION 
IGNORE),  and  is  documented  as:  “Selects  the  partition  with  the  largtst  ‘chunks’  from  a  list  of  partitions.’’. 

TO-DEFAULT-SUB-EXPLA”ATIO:iS  is  a  user  defined  lisp  function  which  lias  an  argument  list  of  (EXPLANA¬ 
TION  IGNORE),  and  is  documented  as:  “ Generates  sub  explanations  from  the  partition  of  an  explanation. 

TO-DEFAULT-u::EXPLAi::ED-uriTS  if  a  user  defined  lisp  function  which  has  an  argument  list  of  (EXPLA¬ 
NATION  IGNORE),  and  is  documented  as:  “ Generates  an  explanation  for  the  ‘misfits’  of  an  explanation.’’. 

A-2.2.5  Units  with  a  prototype  of  Slot 

Explanation-Slot  is  a  slot  which  accepts  values  of  type  Any  Type  and  makes  sense  for  units  of  type 
Explanation  Type.  This  is  (lie  prototypical  slot  referring  to  explanations. 

To-Partition-By  is  a  slot  which  accepts  values  of  type  Any  Type  and  makes  sense  for  units  of  type 
Slot  Type.  This  tells  how  to  partition  by  a  particular  slot.  Its  value  defaults  by  the  function  INHER1T- 
THROUGH-PROTOTYPE,  which: 

Searches  through  the  CORE  PROTOTYPE  slots  of  a  unit  for  a  value. 

Unit-Explanation-Slot  if  a  slot  which  accepts  values  of  type  Any  Type  and  makes  sense  for  units  of  type 
['nil  Explanation  Type.  This  is  the  prototypical  slot  referring  to  unit  explanations. 

Umt-Set-Explanation-Slot  is  a  slot  which  accepts  values  of  type  Any  Ty;n  and  makes  sense  for  units  of 
type  Unit  Set  Explanation  Type.  This  is  the  prototypical  slot  referring  to  unit  set  explanations. 

A-2.2.6  Units  with  a  prototype  of  Typo 

Explanation-Type  specifies  a  class  of  LISP  objects  which  are  classified  by  Unit-Type  and  which  addition¬ 
ally  satisfy  the  predicate  FROTOTYPE-OF-EXPLA”ATIon7  (documented  as  " Checks  to  see  if  a  unit  inherits  from 
CO  RE:  EX  PL  A  IN.EX  PL  A  A'A  T  ION  via  COR  E:PROTOTY PE") .  This  is  a  type  satisifed  by  units  inheriting 
(via  the  Prototype  relation)  from  the  unit  Explanation. 

Unit-Explanation-Type  specifies  a  class  of  LISP  objects  which  are  classified  by  Unit-Type  and  which  ad¬ 
ditionally  satisfy  the  predicate  PR0T0TYPE-0F-U:'IT-E)(PLA"ATI0::7  (document ed  as  ''Chicks  to  •<<  if  a  uwt  in- 
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herita  from  CORE:  EX  PL  A  IN:  UNIT-  EX  PLANA  TION  via  CORE.PROTOTYPE.”}.  This  is  a  type  satisifed 
by  units  inheriting  (via  the  Prototype  relation)  from  the  unit  Unit  Explanation. 

Unit-Set-Explanation-Type  specifies  a  class  of  LISP  objects  which  are  classified  by  Unit-Type  and  which 
additionally  satisfy  the  predicate  PROTOTYPE-OF-UIUT-SET-EXPLAnATION7  (documented  as  “Check;  to  see  if  a 
unit  inherits  from  C0RE:EXPLAIN:VN1T-SET-EXPLAXAT10N  via  CORE.PROTOTYPE .*).  This  is  a 
type  satisifed  by  units  inheriting  (via  the  Prototype  relation)  from  the  unit  Unit  Set  Explanation. 

A-2.2.7  Units  with  a  prototype  of  Unit  Explanation  Slot 

Unit-To-Explain  is  a  slot  which  accepts  values  of  type  Any  Tyjie  and  makes  sense  for  units  of  type  Urn t 
Explanation  Type.  This  is  the  individual  unit  this  explanation  is  about. 

A-2.2.8  Units  with  a  prototype  of  Unit  Set  Explanation  Slot 

These  units  all  have  MAKES-SENSE-FOR  slots  of  Unit-Set-Explanation-Type. 

These  units  are  best  organized  by  the  Data  Type  relation. 

Units  with  a  Data  Type  slot  of  Any-Type 

Sub-Explanations  is  a  slot  which  accepts  values  of  type  Any  Type  and  makes  sense  for  units  of  type  Unit  Set 
Explanation  Type.  These  are  the  explanations  which  are  component  to  this  explanation.  Its  value  defaults 
by  the  function  ARLO:TO-DEFAULT-SUB-EXPLANAT!ONS,  which. 

Generates  sub  explanations  from  the  partition  of  an  explanation. 

Synbolic-Di vision  is  a  slot  which  accepts  values  of  type  Any  Type  and  makes  sense  for  units  of  type 
Unit  Set  Explanation  Type.  This  is  a  symbolic  description  of  the  focus  of  this  explanation. 

Unexplained-Units  is  a  slot  which  accepts  values  of  type  Any  Type  and  makes  sense  for  units  of  type 
Unit  Set  Explanation  Type.  This  is  an  explanation  of  the  units  not  covered  in  this  explanation.  Its  value 
defaults  by  the  function  ARLO:TO-DEFAULT-UNEXPLAlNED-UNlTS,  which: 

Generates  an  explanation  for  the  ‘misfits’  of  an  explanation. 

Units  with  a  Data  Type  slot  of  Integer-Type 

Section-Size  is  a  slot  which  accepts  values  of  type  Integer  Type  and  makes  sense  for  units  of  type  Unit  Set 
Explanation  Type.  This  is  the  threshold  when  explanation  sectionization  is  attempted. 

Units  with  a  Data  Type  slot  of  List-Type 

Relevant -Units  is  a  slot  which  accepts  values  of  type  List  Type  and  makes  sense  for  units  of  type  Unit  Set 
Explanation  Type  This  is  a  list  of  the  units  this  explanation  refers  'o. 

Set -Partitions  is  a  slot  which  accepts  values  of  type  List  Type  and  makes  sense  for  units  of  type  Unit 
Set  Explanation  Type.  This  is  a  list  of  the  possible  partitions  of  this  set  of  units.  Its  value  defaults  by  the 
function  ARLO. TO- DEFAULT-SET-PARTITIONS,  which: 

Computes  or  reduces  (from  its  super-explanation)  the  partitions  for  an  explanation. 

Structural-Slots  is  a  slot  which  accepts  values  of  type  List  Type  and  makes  sense  for  units  of  type  Unit 
Set  Explanation  Typ<  This  i-  a  list  of  the  slots  which  may  sectionize  this  explnnnt ion. 
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